Applying Maven-style exclusions may cause a deprecation warning with Gradle 8.8 #384
Comments
|
Can you please provide a minimal sample that reproduces the warning? As you can see in the stack trace, As such, it's not clear to me why it's apparently being called with a configuration that has already been resolved. |
|
Configurations are partially resolved for task dependencies before they are fully resolved. This process is faster than a full resolution, and allows Gradle to determine which tasks to run while deferring resolution of external dependencies later. When a configuration is partially resolved in this way, beforeResolve is not called. The reason for this deprecation is that mutating the configuration's dependencies between these two resolutions can cause the first (partial) and second (full) resolutions to disagree with each other. In the worst case, this can mean Gradle not executing the proper tasks. Running the |
spring-projects-issues
added
status: feedback-provided
and removed
status: waiting-for-feedback
labels
|
@jvandort Thanks. That's pretty nasty from the dependency management plugin's perspective and its support of Maven-style exclusions. Would it be possible to either change the timing at which An alternative would be to stop supporting Maven-style exclusions with Gradle 9+. I'm not against that as it's by far and away the most complicated part of this plugin, but I am concerned about how it would be received by the community. I know that many people find the Maven-style exclusion support to be useful as suggestions to disable the functionality to avoid or work around a problem have regularly received some pushback. |
|
I'm not sure I'm hitting the same problem: |
|
Thanks, @quaff. That certainly looks very similar. The plugin's |
|
Anyone who's affected by this can avoid the deprecation warning by disabling the plugin's support for honouring Maven's exclusion semantics: // Groovy
dependencyManagement {
applyMavenExclusions = false
}// Kotlin
dependencyManagement {
applyMavenExclusions(false)
}This may result in you having some additional and unwanted dependencies. They would then have to be excluded using one of Gradle's standard mechanisms. |
You could first try to use the While a proper solution to something like this would likely lie with dynamically generating component metadata rules based on a BOM, that is likely not possible at the moment, as I'm not sure these rules can be lazily generated as a result of a resolution. Would you be able to go into a little bit of detail on what the maven-style exclusion support attempts to accomplish? I understand the basic principles that in Maven, if a dependency is excluded from one dependency it gets included from the entire Graph, whereas in Gradle, each dependency that targets a given transitive dependency must exclude that transitive dependency for it to be truly removed from the final graph. How does the dependency management plugin work to resolve this? Without looking too deep into what its doing, it seems that it performs one resolution in order to add excludes to the declared dependencies of another resolution. Instead of mutating the declared dependencies in the callback, would it be possible to instead determine the list of dependencies that would have been excluded in maven and then blanket-exclude those from the configuration-being-resolved? Something like: |
That's exactly it. When the plugin detects that a configuration is about to be resolved (through its
|
|
Where you may run into problems is trying to mutate dependencies that come from a DependencyCollector, as dependencies sourced from there are much more strict. Once you ask a I think you will have much more success applying the exclusions to the configuration as a whole (within |
wilkinsona
changed the title
wilkinsona
added
type: bug
and removed
status: waiting-for-triage
status: feedback-provided
labels
|
I'd still welcome a minimal example that reproduces the problem please. @jvandort, I tried yours with Gradle 8.8 but it does not produce any warnings: Info logging confirmed that some exclusions were applied: |
wilkinsona
changed the title
Yes, It works. |
spring-projects-issues
added
status: feedback-provided
and removed
status: waiting-for-feedback
labels
|
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed. |
|
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue. |
spring-projects-issues
closed this as not planned
|
I've now managed to reproduce the deprecation warning using the example for @jvandort but I had to use an 8.10 nightly. I can't reproduce it with 8.8 or an 8.9 nightly ( @quaff @rpost, I'd still really like to see a reproducer that triggers the warnings with 8.8. Without one, it's difficult to be certain that any fix is going to work as intended and not have unwanted side-effects. |
wilkinsona
added a commit
to wilkinsona/dependency-management-plugin
that referenced
this issue
Jul 1, 2024
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
|
I've pushed a possible fix to my fork. I'd still like to see a reproducer with Gradle 8.8 before merging it. |
|
I prepared one: https://github.com/rpost/sb-gradle-plugin-warning-reproducer When I run |
spring-projects-issues
added
status: feedback-provided
and removed
status: waiting-for-feedback
labels
|
Thanks, @rpost. I've now reproduced the problem with Gradle 8.8. The fix seems to work here too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From gradle execution output ran with
--warning-mode all:The text was updated successfully, but these errors were encountered: