-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Somehow this plugin is excluding junit #21
Comments
Looks like a bug in 0.3.0 that aims to honour Maven exclusions. You may want to try 0.2.1 until a fix is available. Alternatively, declaring a direct dependency on JUnit should also work. |
There is a bug in dependency-management-plugin 0.3.0 which fails the build: spring-gradle-plugins/dependency-management-plugin#21 This reverts commit 14c4ab3.
Unfortunately the direct dependency on junit does not work. I had tried that first :) |
Sorry about that. I'm intrigued now. There's a test that verifies that a direct dependency prevents an exclusion. As an aside, and it won't help with this problem, you should use spring-boot-dependencies rather than spring-boot-versions. |
I was wondering about that. I used the same convention as spring-cloud, although I noticed all spring boot does is pull in the dependencies pom anyway. I have no idea how that test passes based on what I saw, seems like a mystery. |
Here is another weird one. With 0.3.0 this worked
but on 0.2.1 you have to do this
or you get the error
|
Nvm :) |
This should now be fixed in |
Its working for me. Nice work! |
Excellent. Thanks for testing it. |
There is a bug in dependency-management-plugin 0.3.0 which fails the build: spring-gradle-plugins/dependency-management-plugin#21 This reverts commit 14c4ab3.
Previously, the dependency management plugin used a before resolve action to apply Maven-style exclusions. Gradle performs configuration resolution in two passes and, despite its name, a before resolve action is called after the first pass. With Gradle 8.8 and later, using a before resolve action to configure the exclusions can result in a deprecation warning. The deprecation warning states that support for mutating the dependency attributes of a configuration after it has been resolved has been deprecated. This commit addresses the deprecation warning by configuring the exclusions earlier, in the withDependencies callback. The callback is called before the first pass of the resolution process, thereby avoiding the warning. Configuring the exclusions at this step prevents the exclusions from being configured on a per-dependency basis so they are now configured on the configuration. Without any additional changes, this regresses the fix for spring-gradle-pluginsgh-21 as the exclusions are now inherited and cause an exclusion in one configuration where it should apply to leak into another configuration where it should not. To overcome this regression, exclusions are only applied to configurations that can be resolved. Typically, these are configurations like compileClasspath, testRuntimeClasspath and so on, that are leaves and are not extended by other configurations, thereby minimizing the risk of any inheritance-related problems. Closes spring-gradle-pluginsgh-384
Previously, the dependency management plugin used a before resolve action to apply Maven-style exclusions. Gradle performs configuration resolution in two passes and, despite its name, a before resolve action is called after the first pass. With Gradle 8.8 and later, using a before resolve action to configure the exclusions can result in a deprecation warning. The deprecation warning states that support for mutating the dependency attributes of a configuration after it has been resolved has been deprecated. This commit addresses the deprecation warning by configuring the exclusions earlier, in the withDependencies callback. The callback is called before the first pass of the resolution process, thereby avoiding the warning. Configuring the exclusions at this step prevents the exclusions from being configured on a per-dependency basis so they are now configured on the configuration. Without any additional changes, this regresses the fix for gh-21 as the exclusions are now inherited and cause an exclusion in one configuration where it should apply to leak into another configuration where it should not. To overcome this regression, exclusions are only applied to configurations that can be resolved. Typically, these are configurations like compileClasspath, testRuntimeClasspath and so on, that are leaves and are not extended by other configurations, thereby minimizing the risk of any inheritance-related problems. Closes gh-384
To Reproduce:
go to start.spring.io create a new groovy/gradle/java 1.8 project with web, security, and actuator.
Alter the build.gradle to use the dependency management:
The test will fail because of a missing junit dependency:
running gradle dependencies will show that indeed for whatever reason that one dependency is excluded.
Remove the dependency plugin and it works again.
The text was updated successfully, but these errors were encountered: