[
https://issues.apache.org/jira/browse/MRESOLVER-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892535#comment-17892535
]
Tamas Cservenak commented on MRESOLVER-614:
-------------------------------------------
No, I disagree with your assessment, and while true that we see "slight"
differences between (non-transitive) Maven3 and (transitive) Maven4, I am
pretty much sure it is due this issue. In general, transitive depMgt handling
should just improve things IMO.
When I say "in parent", I literally meant "in parent POM", but resolver
receives model builder built POM (hence, same would be true, if a POM is at
n-depth, and contains depMgt entry for Dv1 while it contains dep entry for
Dv2... Dv1 would "won". Resolver is not aware that depMgt is "in parent" nor is
important. The important bit is that depMgt from node at n-depth should be
applied only on n+1 and below depth (to children, so to say, so it's own
dependency dependencies, just like in your POM, the depMgt is not overriding
your deps).
Anyway, the PR looks good IMO and also seems to work (due this issue, Maven 4
beta-5 is unable to build Maven Resolver master, with this patch it can).
> Collector applies depMgt entries coming from a self onto itself
> ---------------------------------------------------------------
>
> Key: MRESOLVER-614
> URL: https://issues.apache.org/jira/browse/MRESOLVER-614
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 2.0.2
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 2.0.3
>
>
> In Maven3 this was not a problem, as Maven3 could add depMgt only on "root
> level".
> In Maven4 with use of new/old transitive Dependency Managers this became a
> problem. The dependency manager first receives depMgt entries for currently
> processed node, and then applies it onto same entry, overriding direct
> dependency versions.
> Example with Maven beta-5: it cannot build Resolver master
> (88a96ac0606d4d2372452a677d9f93c0b55105a4) as bnd-maven-plugin do depend on
> plexus-utils via path of {{bnd-maven-plugin > build-api > plexus-utils}} as
> it explodes due lack of org.plexus.utils.Scanner on classpath. This class was
> introduced in plexus-utils 1.5.8, and build-api do depend on it. But alas,
> build-api parent contains depMgt entry for plexus-utils 1.5.5 and is applied
> onto build-api overriding it's own dependency version.
> Basically current resolver code is NOT prepared for any "transitive
> dependency management" (despite DependencyManagers are there) as node would
> apply it's own depManagement rules onto itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
