[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
---------------------------------
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver 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, it *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 processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, 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 Mojo asks for "compile+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 (and 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
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obvious leads to incomplete build
path{*}.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver 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, it *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 processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, 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.
> 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
>
> This bug affects all released Maven versions.
> Description of the bug: when a Mojo requires Core to collect/resolver 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, it *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 processed by Resolver it will contain nodes from unwanted scopes (as
> Maven Core blindly added all of them from POM, 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 Mojo asks for "compile+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 (and 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 "compile+runtime" requested resolution scope, the "test" scoped
> dependencies are (rightfully) filtered out. {*}This obvious leads to
> incomplete build path{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
