Dependency excludes defined in a beforeResolve hook should be respected
#2480
Labels
Milestone
Comments
eriwen
added
a:bug
affects-version:4.0
from:contributor
in:dependency-management
bigdaz
added a commit
that referenced
this issue
Jul 18, 2017
The introduction of the 'root component metadata' cache (68c0bb3) causes the excludes added in a `beforeResolve` hook to be ignored.
|
Thanks for the report: I've confirmed that this is a problem introduced in Gradle 4.0. The underlying problem is that dependency excludes declared in a |
bigdaz
added a commit
that referenced
this issue
Jul 18, 2017
By executing any `beforeResolve` action at the time the root component metadata is built, we ensure that the cached metadata is correct. However, this is likely to result in `beforeResolve` actions being triggered too early, before the Configuration has been fully configured.
bigdaz
added a commit
that referenced
this issue
Jul 18, 2017
Since we don't track/validate changes to the properties of each Dependency of a configuration, this change assumes that any call to `configuration.incoming.dependencies` implies a mutation.
|
I've added some ideas on how this could be fixed here: https://github.com/gradle/gradle/tree/dd/issue/2480. However, neither of the attempted fixes are particularly satisfactory. |
melix
pushed a commit
that referenced
this issue
Jul 18, 2017
The introduction of the 'root component metadata' cache (68c0bb3) causes the excludes added in a `beforeResolve` hook to be ignored.
bigdaz
changed the title
beforeResolve hook should be respected
bigdaz
added a commit
that referenced
this issue
Jul 19, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See attached project. Assemble with Gradle 4 (the included Gradle wrapper is 4). The WAR will contain
WEB-INF/lib/XmlSchema-1.1.jar(and a duplicate file error), even though this dependency is excluded and not print bygradle dependencies.Build the same project using Gradle 3 and the WAR contents will be correct.
I created this issue with Spring dependency plugin project first, Since the sample project uses the plugin. But the contributors pointed out, that the same error also occurs when not using the plugin. See comment on the linked issue.
The text was updated successfully, but these errors were encountered: