[
https://issues.apache.org/jira/browse/MASSEMBLY-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17905136#comment-17905136
]
Eric Yu commented on MASSEMBLY-1031:
------------------------------------
DependencyResolver resolved Artifacts have *not scope.*
[https://github.com/apache/maven-assembly-plugin/blob/9f9def031952139f543852459548629c2af9b249/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java#L192-L193]
> Regression: assembly plugin 3.7.0 now includes scope=provided dependencies if
> they also occur transitively
> ----------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-1031
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1031
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Affects Versions: 3.7.0, 3.7.1
> Reporter: K P
> Priority: Blocker
>
> 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
>
> {code:java}
> <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>{code}
>
>
> * 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:
>
> {code:java}
> <dependencySets>
> <dependencySet>
> <outputDirectory>libs/</outputDirectory>
> <useProjectArtifact>false</useProjectArtifact>
> <unpack>false</unpack>
> </dependencySet>
> </dependencySets> {code}
>
>
> h1. maven-assembly-plugin 3.6.0
> generates a zip with +*only*+ the following dependency in the zip:
> {code:java}
> libs\commons-text-1.12.0.jar{code}
> as 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.
> h1. maven-assembly-plugin 3.7.0
> generates a zip with +*both*+ dependencies in the zip:
> {code:java}
> libs\commons-lang3-3.14.0.jar
> libs\commons-text-1.12.0.jar{code}
> So 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
