[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak edited comment on MNG-7906 at 2/5/24 6:48 PM:
--
Moreover, to extend Guillaumes point: "project version" {{G:A:1.x}} can change
to {{G:A2:2.x}} as Maven GAV (you have two more coordinates to "express" the
intent) is not "version only" as in npm, ruby-gems etc. You could even "encode"
major version in A, so shift in x.y.z version into {{groupId:artifact-x:y.z}}
or alike (this is just for example sake). Moreover, there is a long history of
changes like these even in ASF history.
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
was (Author: cstamas):
Moreover, to extend Guillaumes point: "project version" {(A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (you have two more coordinates to "express" the
intent) is not "version only" as in npm, ruby-gems etc. You could even "encode"
major version in A, so shift in x.y.z version into {{groupId:artifact-x:y.z}}
or alike (this is just for example sake). Moreover, there is a long history of
changes like these even in ASF history.
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak edited comment on MNG-7906 at 2/5/24 6:47 PM:
--
Moreover, to extend Guillaumes point: "project version" {(A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (you have two more coordinates to "express" the
intent) is not "version only" as in npm, ruby-gems etc. You could even "encode"
major version in A, so shift in x.y.z version into {{groupId:artifact-x:y.z}}
or alike (this is just for example sake). Moreover, there is a long history of
changes like these even in ASF history.
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
was (Author: cstamas):
Moreover, to extend Guillaume point: "project version" {(A:1.x}} can change to
\{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to
"express" the intent) not found.) is not "version only". You could even
"encode" major version in A, so shift in x.y.z version into
{{groupId:artifact-x:y.z}} or alike (this is just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak edited comment on MNG-7906 at 2/5/24 6:45 PM:
--
Moreover, to extend Guillaume point: "project version" {(A:1.x}} can change to
\{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to
"express" the intent) not found.) is not "version only". You could even
"encode" major version in A, so shift in x.y.z version into
{{groupId:artifact-x:y.z}} or alike (this is just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
was (Author: cstamas):
Moreover, to extend Guillaume point: "project version" != "artifact version"
(or it does not have to be). There is a long history, that a project that
evolves, and assuming it gets incompatible changes, change the GAV as well (to
be clear about incompatible changes). So, {{G:A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to "express"
the intent!) is not "version only". You could even "encode" major version in A,
so shift in x.y.z version into {{groupId:artifact-x:y.z}} or alike (this is
just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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 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
>
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813051#comment-17813051
]
Herve Boutemy edited comment on MNG-7906 at 2/1/24 6:25 AM:
{quote}So I think the first step would be to add a WARNING when the POM being
built contains a managed dependency which is lost because not first.
This will explain to the user what's wrong and that the dependency should be
moved up at the top of the managed dependency section in order to be useful.
That should be easily done and back ported to 3.9.x.
{quote}
this idea about warning *only on the POM being built* is the right approach:
not too noisy, actionable, not breaking anything
(going back to the dependencyManagement import topic)
was (Author: hboutemy):
{quote}So I think the first step would be to add a WARNING when the POM being
built contains a managed dependency which is lost because not first.
This will explain to the user what's wrong and that the dependency should be
moved up at the top of the managed dependency section in order to be useful.
That should be easily done and back ported to 3.9.x.
{quote}
this idea about warning *only on the POM being built* is the right approach:
not too noisy, actionable, not breaking anything
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786533#comment-17786533
]
Tamas Cservenak edited comment on MNG-7906 at 11/15/23 10:48 PM:
-
Well, in maven deps it work like it: the "closer" it is, it "wins".
For example, if you have guice as dependency, whether you declare direct
dependency on guava before or after guice, it will "win".
But in case of depMgr this is NOT the case, and is counter intuitive. It will
work ONLY if you declare depMgt entry BEFORE.
was (Author: cstamas):
Well, in maven deps it work like it: the "closer" it is, it "wins".
For example, if you have guice as dependency, whether you declare direct
dependency on guava before or after guice, it will "win".
but in case of depMgr this is NOT the case, and is counter intuitive.
> 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
>Reporter: Tamas Cservenak
>Priority: Blocker
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786533#comment-17786533
]
Tamas Cservenak edited comment on MNG-7906 at 11/15/23 10:48 PM:
-
Well, in maven deps it work like it: the "closer" it is, it "wins".
For example, if you have guice as dependency, whether you declare direct
dependency on guava before or after guice, it will "win".
But in case of depMgr this is NOT the case, and is counter intuitive. It will
work ONLY if you declare depMgt entry BEFORE (as it is "first wins"
implemented).
was (Author: cstamas):
Well, in maven deps it work like it: the "closer" it is, it "wins".
For example, if you have guice as dependency, whether you declare direct
dependency on guava before or after guice, it will "win".
But in case of depMgr this is NOT the case, and is counter intuitive. It will
work ONLY if you declare depMgt entry BEFORE.
> 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
>Reporter: Tamas Cservenak
>Priority: Blocker
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786533#comment-17786533
]
Tamas Cservenak edited comment on MNG-7906 at 11/15/23 10:47 PM:
-
Well, in maven deps it work like it: the "closer" it is, it "wins".
For example, if you have guice as dependency, whether you declare direct
dependency on guava before or after guice, it will "win".
but in case of depMgr this is NOT the case, and is counter intuitive.
was (Author: cstamas):
Well, if maven deps it work like it: the "closer" it is, it "wins".
For example, if you have guice as dependency, whether you declare direct
dependency on guava before or after guice, it will "win".
but in case of depMgr this is NOT the case, and is counter intuitive.
> 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
>Reporter: Tamas Cservenak
>Priority: Blocker
> 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)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782960#comment-17782960
]
Herve Boutemy edited comment on MNG-7906 at 11/5/23 8:07 AM:
-
I know it's suprising, particularly when we have no way to see the path to an
imported dependencyManagement (see MPH-183 MNG-7344)
I'm not convinced having the latest import override first imports really makes
sense: order in dependency declaration matters
but for sure, currently debugging nested dependencyManagement import is hard: I
saw it on sigstore-maven-plugin 0.4.0 where the import tree is huge
was (Author: hboutemy):
I know it's suprising, particularly when we have no way to see the path to an
imported dependencyManagement (see MPH-183 MNG-7344)
I'm not convinced having the latest import override first imports really makes
sense: order in dependency declaration matters
> 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
>Reporter: Tamas Cservenak
>Priority: Blocker
> 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)
