[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813854#comment-17813854
]
Henning Schmiedehausen edited comment on MNG-7906 at 2/2/24 11:34 PM:
----------------------------------------------------------------------
[~cstamas] you literally made my point. I was not about "highest version wins"
(I wrote that but it is incorrect as you pointed out). My main point is that
maven works under the assumption that every version is always backwards
compatible to each other.
If you have a dependency A that uses library "1.0.0" and then add that library
to your pom with version "2.0.0", you end up with "2.0.0". And that is
{*}wrong{*}. The build should *fail.* Because there is no guarantee that you
can replace 1.0.0 with 2.0.0.
The other way around is worse: if you have a library that declares a dependency
"1.1.0" and then you use the "1.0.0" dependency, you downgrade a transitive
dependency with a non-compatible version.
This behavior is the sole reason why the dvc plugin exists.
I very much heard the point that this statement is incorrect, but not because
"best wins" but "nearest wins". So let me rephrase that (and I will update the
plugin pages) :
*Apache Maven operates under the assumption that it can replace any dependency
version with any other version based on a "closest to the root wins" algorithm,
that makes it almost impossible to predict which version of a dependency will
end up in the build unless all used dependencies are locked down (e.g. by
adding <dependencyManagement> entries and the resulting build tree is analyzed
to ensure that the different packages end up with versions that are compatible.
Maven has no builtin concept of backward or forward compatible versions, it
assumes that every version can be replaced with any other version based on this
"nearest is best" algorithm and the resulting tree still makes sense.*
Not sure that this makes your life easier or better. Let me know if you can
agree or disagree that this statement reflects reality better.
My *recommendation* would be that we start adopting an actual compatibility
policy (semantic versioning seems to have won) but allow projects to override
that policy (maybe with a new element in the POM; 4.0.0 may be a good
opportunity). But the current behavior is so poorly understood that people are
bound to get it wrong. I got it wrong. :)
was (Author: henning):
[~cstamas] you literally made my point. I did not say anywhere that "highest
version wins". I said that maven works under the assumption that every version
is always backwards compatible to each other.
If you have a dependency A that uses library "1.0.0" and then add that library
to your pom with version "2.0.0", you end up with "2.0.0". And that is
{*}wrong{*}. The build should *fail.* Because there is no guarantee that you
can replace 1.0.0 with 2.0.0.
The other way around is worse: if you have a library that declares a dependency
"1.1.0" and then you use the "1.0.0" dependency, you downgrade a transitive
dependency with a non-compatible version.
This behavior is the sole reason why the dvc plugin exists.
I very much heard the point that this statement is incorrect, but not because
"best wins" but "nearest wins". So let me rephrase that (and I will update the
plugin pages) :
*Apache Maven operates under the assumption that it can replace any dependency
version with any other version based on a "closest to the root wins" algorithm,
that makes it almost impossible to predict which version of a dependency will
end up in the build unless all used dependencies are locked down (e.g. by
adding <dependencyManagement> entries and the resulting build tree is analyzed
to ensure that the different packages end up with versions that are compatible.
Maven has no builtin concept of backward or forward compatible versions, it
assumes that every version can be replaced with any other version based on this
"nearest is best" algorithm and the resulting tree still makes sense.*
Not sure that this makes your life easier or better. Let me know if you can
agree or disagree that this statement reflects reality better.
My *recommendation* would be that we start adopting an actual compatibility
policy (semantic versioning seems to have won) but allow projects to override
that policy (maybe with a new element in the POM; 4.0.0 may be a good
opportunity). But the current behavior is so poorly understood that people are
bound to get it wrong. I got it wrong. :)
> 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)
