[
https://issues.apache.org/jira/browse/MRESOLVER-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892518#comment-17892518
]
Didier Loiseau commented on MRESOLVER-614:
------------------------------------------
This is the kind of issue I was worried about in MNG-8190…
{quote}
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.
{quote}
This is really weird, how come the parent overrides the version specified
explicitly in the child?
On the other hand, the dependency management is there, so it should be taken
into account… As I understand it, your fix is to ignore it when the
{{<dependencies>}} override the version specified in the
{{<dependencyManagement>}}? For me this makes sense indeed, as what we want is
to have the same dependencies as when the child was built.
Watch out for optional dependencies too, as I have noticed they behave the same
as dependency management.
p.s. it seems you found an old Apache Jira account of mine there 😅
> 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)
