[ 
https://issues.apache.org/jira/browse/MRESOLVER-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892541#comment-17892541
 ] 

Didier Loiseau commented on MRESOLVER-614:
------------------------------------------

{quote}In general, transitive depMgt handling should just improve things IMO.
{quote}
Oh I totally agree with that. In fact, I would even argue that, if it causes 
any issue, the project is probably misconfigured. But some may still consider 
it a regression. (OTOH, they can continue to use Maven 3)
{quote}Resolver is not aware that depMgt is "in parent" nor is important.
{quote}
Yes indeed, in this case it is in parent but it could even be in the same pom.
{quote}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).
{quote}
That makes sense indeed. (y)

> 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)

Reply via email to