[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
---------------------------------
Fix Version/s: 3.9.7
4.0.0
4.0.0-alpha-13
> Maven Core bug regarding resolution scopes for Mojos
> ----------------------------------------------------
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
> Reporter: Tamas Cservenak
> Priority: Major
> Fix For: 3.9.7, 4.0.0, 4.0.0-alpha-13
>
>
> This bug affects all released Maven versions.
> Reproducer: [https://github.com/cstamas/MNG-8041]
> Description of the bug: when a Mojo requires Core to collect/resolve given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, DPDR *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request is processed by Resolver, it will contain nodes from unwanted scopes
> (as Maven Core blindly added all of them from POM. Also, if Resolver would be
> asked to create root, it would NOT add these in the first place), and due
> that, conflict resolver may possibly eliminate other nodes (as POM ones
> "always wins", are closest to graph root), and also, even the winners will be
> eliminate in subsequent step, for example due scope filtering. This results
> in incomplete resolution scope.
> Consequence: let's consider example where Mojo asks for "runtime" resolution
> scope. To serve this, Maven will add ALL dependencies present in POM to
> collect request (even those in scopes to be omitted, like "test" scoped
> ones), and will perform "collect" with Resolver. When Resolver returns, the
> graph will contain nodes (as 1st level, as they are POM direct
> dependendencies) that MAY be contained in deeper nodes of non-test scoped
> ones (the guice+guava example). Next, "conflict resolution" happens, and
> naturally all the "test" scoped 1st level dependencies "win", rendering
> removal of others. Finally, due "runtime" requested resolution scope, the
> "test" scoped dependencies are (rightfully) filtered out. {*}This obviously
> leads to incomplete runtime build path{*}.
> Or in other words, Maven is wrong here: it adds 1st level dependencies to
> CollectRequest that should not be there in the first place (in example above,
> the "test" scoped ones), that will cause that Resolver "collect" step build a
> graph that has "unwanted" scoped nodes closer to root than actually needed
> runtime dependencies (remember: test nodes will be not affected by filter, as
> they are already present, added by Maven, and test node children are
> collected also as "runtime", just to have "test" scope inherited later in the
> process, hence all the children of "test" node will end up in "test" scope,
> despite "exclude test" is present!), this will cause that in dependency
> conflict resolution step, they will kick out all the rightful runtime
> dependencies, and finally, all these winners are removed due scope filter.
> Implication of this bug is following important fact: the project "runtime"
> resolution scope (as when asked by Mojo) and project "runtime" resolution
> scope (as when used as a dependency on some downstream project) {*}were not
> the same{*}!
> Effects of this bug are explained in "Important Consequences" section of this
> page
> [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
> (that is wrongly written: all that is a consequence of this bug). Also, have
> to note, that when this bug get addressed, it will NOT render "workarounds"
> broken (ie. introduction of another module just to package "runtime"
> classpath using m-assembly-p or alike plugins), just "obsolete", as packaging
> of runtime dependencies will become possible in-situ (in the same module of
> the project).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
