[MASSEMBLY-1031] Regression: assembly plugin 3.7.0 now includes scope=provided dependencies if they also occur transitively #1236
Description
K P opened MASSEMBLY-1031 and commented
Since maven-assembly-plugin 3.7.0, dependencies with scope=provided are included in the dependency set, when they're also present transitively with compile scope. This behaviour was different in all previous version of maven-assembly-plugin.
+Reproducible scenario:+
Assume a simple project.
With 2 dependencies.
We have an assembly to create an archive (zip) that includes our project jar, and its dependencies in a directory "lib" in the archive.
As a simple reproducible example, let's assume these 2 simple Apache commons dependencies
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-text</artifactId>
<version>1.12.0</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.14.0</version>
<scope>provided</scope>
</dependency>
- commons-text , with scope = compile (default)
- commons-lang3 , with scope = +provided+
Note:
commons-text itself has a transitive dependency on commons-lang3.
But in our project we explicitly have our own commons-text dependency (e.g. because some or our own project code refers to it and we don't want to rely on commons-lang3 to pull it in transitively by chance) and it has scope = provided (e.g. because let's assume, that for whatever reason, this commons-lang3 is always present on the target system for which we create this zip, and therefore we don't want to publish it in our own assembled .zip)
So the expectation is that we have +only+ commons-text in our .zip.
When executing mvn dependency:list, you nicely see that maven resolves the dependencies as follows:
[INFO] The following files have been resolved:
[INFO] org.apache.commons:commons-text:jar:1.12.0:{*}compile{*}
[INFO] org.apache.commons:commons-lang3:jar:3.14.0:{*}provided{*}
i.e. in its overall picture of dependencies:
- commons-text nicely resolves as a compile dependency, commons-lang3 is marked is provided. As expected.
- In the dependency tree commons-lang3 is found transitively 1 level deep as a child of commons-text, and is found in our own pom, at the top-level as direct dependency. The dependency "highest" in the hierarchy tree wins, i.e. our own provided-scoped commons-lang3.
Now we have an assembly that includes the dependencies in a zip:
<dependencySets>
<dependencySet>
<outputDirectory>libs/</outputDirectory>
<useProjectArtifact>false</useProjectArtifact>
<unpack>false</unpack>
</dependencySet>
</dependencySets>
maven-assembly-plugin 3.6.0
generates a zip with +only+ the following dependency in the zip:
libs\commons-text-1.12.0.jaras expected! We do not want the dependency with scope = provided, because that's exactly the point of using the provided scope: it's assumed to be present on target systems.
maven-assembly-plugin 3.7.0
generates a zip with +both+ dependencies in the zip:
libs\commons-lang3-3.14.0.jar
libs\commons-text-1.12.0.jarSo this is already a regression issue: simply upgrading the plugin from 3.6.0 to 3.7.0 broke our builds and our published artifacts! (in a more complex scenario where it wasn't so easy to notice as here)
And now the assembly plugin includes dependencies with scope = provided...
Setting useTransitiveDependencies=false is not a solution, because in more complex examples, there will be other transitive dependencies that we actually want to include. (and are not overruled by our explicit provided scope)
A temporary workaround can be adding an explicit exclusion on the parent dependency, to suppress the transitive dependency. But of course that assumes that at any time you known all the transitive dependencies that may be present somewhere in its hierarchy for any given version, so that you can add exclusion from them in your pom, if you happen to have some of them explicitly with scope provided in your pom.
Affects: 3.7.0, 3.7.1
2 votes, 5 watchers