[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812637#comment-17812637
]
Tamas Cservenak commented on MNG-7906:
--------------------------------------
I have several issues with statements in previous post, but the major one is
this: it references a plugin page that has following statement "Apache Maven
operates under the assumption that every dependency is always backwards
compatible and when two versions are compared, using the 'higher' version will
satisfy any dependency". Am unsure from where [~henning] takes this to be
granted, or even assumes this statement is true, as source code of resolver
does NOT show this at all (or please point me to the code that implements this
behaviour).
What I know, is that we most probably talk about "conflict resolution". The
Javadoc of conflict resolver is here:
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/ConflictResolver.java#L37-L54]
It points us ("The exact rules by which a winning node and its effective scope
are determined are controlled by user-supplied implementations of
VersionSelector...") toward version selector:
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L41-L42]
In short, the statement quoted does not stand at all ("operates under the
assumption that every dependency is always backwards compatible and when two
versions are compared, using the 'higher' version will satisfy any dependency")
for Maven3. Someone very interested in this topic may do a homework, and dig
into Maven2 source code and be surprised.
Maven will choose "nearest version" not "highest version". As graph root is
level 0, is your POM or root dependency of graph being collected, each node has
well defined distance from root: the length of the path you need to make to get
from root to given node. And the most interesting thing: user DO have saying
here, as direct dependencies on POM have distance 1, so they will always win.
In other words, user CAN affect what is chosen for "winner".
> Dependency Management import does not work the "maven way"
> ----------------------------------------------------------
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
> Reporter: Tamas Cservenak
> Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
