[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812528#comment-17812528
]
Henning Schmiedehausen commented on MNG-7906:
---------------------------------------------
the major problem of each of these resolver discussions is BTW summarized on
this page:
[https://basepom.github.io/dependency-versions-check-maven-plugin/development/]
*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.*
As long as this assumption is baked into maven (IAW, replacing "0.0.1" with
"1.0.0" is fine) and maven does not fail as soon as it finds two different
versions of the same dependency referenced in the dependency tree (with
subsequent human input to decide whether two versions for a given artifact are
compatible or not), I see no real point to discuss how dependency resolution
should work and which version should "win".
Other ecosystems have e.g. baked Semantic versioning into their dependency
model. Java/Maven has not (because it predates it by years).
Unless Maven starts encouraging (enforcing?) artifacts to create a version
policy (e.g. "this artifact follows semantic versioning") and maven can consume
that and behave accordingly, I am not sure why we try to "fix" the resolve
behavior. The best bet IMHO is to simply accept that we have settled on the way
the resolver works today, the maven users rely on it and stop trying to improve
it.
e.g. semantic versioning would mean that you can NOT replace 1.0.0 with 2.0.0.
Which maven happily does today.
> 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)
