[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824087#comment-17824087
]
Alexey Loubyansky commented on MRESOLVER-503:
-
Thanks for clarifying all that [~cstamas] I guess the issue can be closed.
Perhaps there should be an issue for maven-dependency-plugin though to be
aligned with the resolver, iiuc
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824074#comment-17824074
]
Alexey Loubyansky commented on MRESOLVER-503:
-
Just to clarify, in Maven 4 the original examples as shown in this issue would
not change?
Only if I add a version of json-smart to the dependencyManagement of msal4j
then I can enforce the version i want?
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824069#comment-17824069
]
Alexey Loubyansky commented on MRESOLVER-503:
-
Huh :) Thanks for all the info!
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824065#comment-17824065
]
Alexey Loubyansky commented on MRESOLVER-503:
-
Sorry, it's still confusing. Let's imagine oauth2-oidc-sdk depended on just
2.4.8 instead of the version range. Would 2.4.8.redhat-1 be the winner in
this case?
If a version range is "replaced" with all the available versions and the
conflict resolution continues "as usual", I still don't understand why a node
on a lower level wins.
I guess it means a version from a version range (no matter on which dependency
level it is found) will have to be selected. And so, if there are multiple
version ranges found in a dependency graph for the same artifact, the latest
from the intersection of those ranges would have to be selected?
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824052#comment-17824052
]
Alexey Loubyansky commented on MRESOLVER-503:
-
What this shows to me is thata developer of msal4j can't be sure the dependency
versions he/she configured in its POM are not guaranteed to be preserved when
msal4j is used in another project, even if it's the only dependency of that
project. Is that correct?
Is a dependencyManagement section or BOM the only way to guarantee dependency
versions?
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824051#comment-17824051
]
Alexey Loubyansky commented on MRESOLVER-503:
-
> Resolver fulfils this by choosing version that suits both
What does "suit" mean though? The redhat version is outside the range it
appears. So in this case it picks the latest from the version range on a lower
level.
Is there a clear rule how version ranges are resolved across the graph? Thanks.
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824046#comment-17824046
]
Alexey Loubyansky commented on MRESOLVER-503:
-
Even if 2.4.8.redhat-1 is a direct dependency of the root? Meaning a direct
dependency the root node can be overridden by a version range used by a
transitive dependency?
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824015#comment-17824015
]
Alexey Loubyansky commented on MRESOLVER-503:
-
The thing is that `dependency:tree` matches my expectations more than the
result I get from the resolver API calls. I'd like to clarify why in case of
the resolver API approach `json-smart` is picked at a lower level. Thanks.
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
[
https://issues.apache.org/jira/browse/MRESOLVER-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Loubyansky updated MRESOLVER-503:
Issue Type: Bug (was: New Feature)
> Differences between results of dependency:tree and direct resolver API calls
>
>
> Key: MRESOLVER-503
> URL: https://issues.apache.org/jira/browse/MRESOLVER-503
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Alexey Loubyansky
>Priority: Major
>
> I noticed a difference in dependency trees produced by dependency:tree and
> what seems to be an equivalent invocation of the resolver using its API.
> It can be reproduced by applying the following change to the maven-resolver
> demo class
> [https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
> Running that results in
> {code:java}
> com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> +- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
> | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
> | +- com.nimbusds:content-type:jar:2.2 [compile]
> | +- net.minidev:json-smart:jar:2.4.8 [compile]
> | +- com.nimbusds:lang-tag:jar:1.6 [compile]
> | \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
> +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
> \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
> Notice the position of json-smart in the tree - it's a dependency of
> oauth2-oidc-sdk in this case.
> Now
> {code:java}
> cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
> {code:java}
> mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
> {code}
> The output is
> {code:java}
> [INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
> [INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
> [INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
> [INFO] | +- com.nimbusds:content-type:jar:2.2:compile
> [INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
> [INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
> [INFO] +- net.minidev:json-smart:jar:2.4.8:compile
> [INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
> [INFO] | \- org.ow2.asm:asm:jar:9.1:compile
> [INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
> [INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
> [INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
> [INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
> [INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
> In this case json-smart is shown as a direct dependency of msal4j, which it
> is in its POM.
> Following the preference of the nearest to the root, dependency:tree seems to
> be correct, isn't it?
> In any case, I'd expect the same result (for compile scope) dependencies out
> of of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-503) Differences between results of dependency:tree and direct resolver API calls
Alexey Loubyansky created MRESOLVER-503:
---
Summary: Differences between results of dependency:tree and direct
resolver API calls
Key: MRESOLVER-503
URL: https://issues.apache.org/jira/browse/MRESOLVER-503
Project: Maven Resolver
Issue Type: New Feature
Components: Resolver
Reporter: Alexey Loubyansky
I noticed a difference in dependency trees produced by dependency:tree and what
seems to be an equivalent invocation of the resolver using its API.
It can be reproduced by applying the following change to the maven-resolver
demo class
[https://github.com/apache/maven-resolver/compare/master...aloubyansky:maven-resolver:dep-tree-diff?expand=1]
Running that results in
{code:java}
com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
+- com.nimbusds:oauth2-oidc-sdk:jar:9.35 [compile]
| +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1 [compile]
| +- com.nimbusds:content-type:jar:2.2 [compile]
| +- net.minidev:json-smart:jar:2.4.8 [compile]
| +- com.nimbusds:lang-tag:jar:1.6 [compile]
| \- com.nimbusds:nimbus-jose-jwt:jar:9.22 [compile]
+- org.slf4j:slf4j-api:jar:1.7.36.redhat-2 [compile]
\- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1 [compile] {code}
Notice the position of json-smart in the tree - it's a dependency of
oauth2-oidc-sdk in this case.
Now
{code:java}
cd ~/.m2/repository/com/microsoft/azure/msal4j/1.13.1.redhat-1{code}
{code:java}
mvn dependency:tree -f msal4j-1.13.1.redhat-1.pom -Dscope=compile
{code}
The output is
{code:java}
[INFO] com.microsoft.azure:msal4j:jar:1.13.1.redhat-1
[INFO] +- com.nimbusds:oauth2-oidc-sdk:jar:9.35:compile
[INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:compile
[INFO] | +- com.nimbusds:content-type:jar:2.2:compile
[INFO] | +- com.nimbusds:lang-tag:jar:1.6:compile
[INFO] | \- com.nimbusds:nimbus-jose-jwt:jar:9.22:compile
[INFO] +- net.minidev:json-smart:jar:2.4.8:compile
[INFO] | \- net.minidev:accessors-smart:jar:2.4.8:compile
[INFO] | \- org.ow2.asm:asm:jar:9.1:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.7.36.redhat-2:compile
[INFO] +- org.projectlombok:lombok:jar:1.18.6:provided
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2.1:compile
[INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
[INFO] \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile {code}
In this case json-smart is shown as a direct dependency of msal4j, which it is
in its POM.
Following the preference of the nearest to the root, dependency:tree seems to
be correct, isn't it?
In any case, I'd expect the same result (for compile scope) dependencies out of
of both approaches. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786336#comment-17786336 ] Alexey Loubyansky commented on MRESOLVER-391: - [~cstamas] I think I understand your point about the current implementation of the resolver. What is not entirely clear to me is whether you see this issue, which is called "Scope mediation improvements", as an issue and if so, what do you think needs to change (in the resolver, i guess, since it's an MRESOLVER issue at this point) to resolve it? > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-391) Scope mediation improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780992#comment-17780992
]
Alexey Loubyansky edited comment on MRESOLVER-391 at 10/30/23 3:50 PM:
---
> There is no "production part" of "test" graph.
I should really have used *runtime* instead of {*}production{*}.
> Graph is this or that, not both, should not be assumed "overlapping".
I agree with that. I don't think though that how a graph is resolved currently
is how it should be done.
> When one asks resolver to collect (or resolve), resolver will perform based
> on input. And the result is either this or that, but not both.
Right, also agreed.
> Hence, this issue should be more like a "discussion" to decide what is right
> behavior of resolver in these cases
No problem with that either.
> for sure there are some edge cases (like silent version bump from 1.x to
> 2.x), but still, it does happen per user instruction (who authors POM)
Well, kind of... This needs to be clarified though.
The mentioned `dependency-scope-maven-plugin`, this and other issues referenced
from this issue wouldn't have been created if users did mean to instruct the
resolver to do what it actually did. Meaning, from the perspective of users who
created these Jira issues their instructions have been misinterpreted. There is
nothing wrong with that in principle, this happens "everywhere every time". But
let's look into what the complaint is actually about.
The issue is that, while resolving version conflicts between transitive runtime
and test dependencies, the resolver will not necessarily prioritize the runtime
versions. It's not about semantic versioning or some other compatibility hints.
It's simply about runtime transitive dependencies not being prioritized. This
leads to tests being compiled and run against a classpath that has been
manipulated by the resolver in a non-intuitive way, which may cause all the
issues described in this and other similar Jira issues. These issues appear in
user projects and have to be fixed either directly in user projects by
performing analysis and adjusting the POM or in the resolver implementation by
prioritizing the runtime transitive dependencies when resolving conflicts.
Let's explore what the option of adjusting user POMs actually means. Let's
suppose that I have a project with 50 direct dependencies (runtime + test) that
builds and runs w/o a problem. I need to update one of those direct
dependencies (a dependabot PR, a CVE fix, etc), while applying this fix I run
into this issue and I am thinking how I should fix my project config. I have a
couple of options:
1) add the overridden version of the runtime transitive dependency to the
dependencyManagement config;
2) add the overridden runtime transitive dependency as a direct runtime
dependency.
Probably either could work as a temporary workaround but none of the above is a
good long term fix. Because at some point I will be bumping the version of that
direct dependency again and the question will be what should happen to the
workaround I applied on the previous update? Assuming I will remember what I
actually did and why. It's really easy to mess it up in a big project
maintained by a team of developers applying all sorts of changes. It's a user
problem but it is a problem that could be avoided by fixing this issue in the
resolver. Let's imagine I did remember exactly what I did and why. I suppose
the changes I applied to dependency configuration as a workaround should be
reverted, the new version of the dependency I want to update should be applied
and the analysis to catch transitive runtime version overrides should be re-run
and possibly a new dependency config adjustment should be applied?
Because if I don't do that then the workaround I applied previously will remain
in my POM and will evolve on its own with version updates (from dependabot for
example) and so on.
Is this the expected workflow or am I missing something? Thanks.
was (Author: aloubyansky):
> There is no "production part" of "test" graph.
I should really have used *runtime* instead of {*}production{*}.
> Graph is this or that, not both, should not be assumed "overlapping".
I agree with that. I don't think though that how a graph is resolved currently
is how it should be done.
> When one asks resolver to collect (or resolve), resolver will perform based
> on input. And the result is either this or that, but not both.
Right, also agreed.
> Hence, this issue should be more like a "discussion" to decide what is right
> behavior of resolver in these cases
No problem with that either.
> for sure there are some edge cases (like silent version bump from 1.x to
> 2.x), but still, it does happen per user instruction (who authors POM)
Well, kind of... This needs to be clarified though.
The mention
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780992#comment-17780992
]
Alexey Loubyansky commented on MRESOLVER-391:
-
> There is no "production part" of "test" graph.
I should really have used *runtime* instead of {*}production{*}.
> Graph is this or that, not both, should not be assumed "overlapping".
I agree with that. I don't think though that how a graph is resolved currently
is how it should be done.
> When one asks resolver to collect (or resolve), resolver will perform based
> on input. And the result is either this or that, but not both.
Right, also agreed.
> Hence, this issue should be more like a "discussion" to decide what is right
> behavior of resolver in these cases
No problem with that either.
> for sure there are some edge cases (like silent version bump from 1.x to
> 2.x), but still, it does happen per user instruction (who authors POM)
Well, kind of... This needs to be clarified though.
The mentioned `dependency-scope-maven-plugin`, this and other issues referenced
from this issue wouldn't have been created if users did mean to instruct the
resolver to do what it actually did. Meaning, from the perspective of users who
created these Jira issues their instructions have been misinterpreted. There is
nothing wrong with that in principle, this happens "everywhere every time". But
let's look into what the complaint is actually about.
The issue is that, while resolving version conflicts between transitive runtime
and test dependencies, the resolver will not necessarily prioritize the runtime
versions. It's not about semantic versioning or some other compatibility hints.
It's simply about runtime transitive dependencies not being prioritized. This
leads to tests being compiled and run against a classpath that has been
manipulated by the resolver in a non-intuitive way, which may cause all the
issues described in this and other similar Jira issues. These issues appear in
user projects and have to be fixed either directly in user projects by
performing analysis and adjusting the POM or in the resolver implementation by
prioritizing the runtime transitive dependencies when resolving conflicts.
Let's explore what the option of adjusting user POMs actually means. Let's
suppose that I have a project with 50 direct dependencies (runtime + test) that
builds and runs w/o a problem. I need to update one of those direct
dependencies (a dependabot PR, a CVE fix, etc), while applying this fix I run
into this issue and I am thinking how I should fix my project config. I have a
couple of options:
1) add the overridden version of the runtime transitive dependency to the
dependencyManagement config;
2) add the overridden runtime transitive dependency as a direct runtime
transitive dependency.
Probably either could work as a temporary workaround but none of the above is a
good long term fix. Because at some point I will be bumping the version of that
direct dependency again and the question will be what should happen to the
workaround I applied on the previous update? Assuming I will remember what I
actually did and why. It's really easy to mess it up in a big project
maintained by a team of developers applying all sorts of changes. It's a user
problem but it is a problem that could be avoided by fixing this issue in the
resolver. Let's imagine I did remember exactly what I did and why. I suppose
the changes I applied to dependency configuration as a workaround should be
reverted, the new version of the dependency I want to update should be applied
and the analysis to catch transitive runtime version overrides should be re-run
and possibly a new dependency config adjustment should be applied?
Because if I don't do that then the workaround I applied previously will remain
in my POM and will evolve on its own with version updates (from dependabot for
example) and so on.
Is this the expected workflow or am I missing something? Thanks.
> Scope mediation improvements
>
>
> Key: MRESOLVER-391
> URL: https://issues.apache.org/jira/browse/MRESOLVER-391
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Original issue description was: "As per MNG-5988: if an artifact in "test"
> scope is found nearer, but in scope "compile" is found deeper in graph, the
> "test" scope wins. This at runtime may lead to CNFEx."
> This is completely wrong premise, and it contains following false assumptions:
> * The "test" classpath is superset of "runtime" classpath. Is not.
> * (derived from that above) To get "runtime" classpath collect via resolver
> "test" classpath and cherry-pick non-"test" (or filter out "test") scoped
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780907#comment-17780907
]
Alexey Loubyansky commented on MRESOLVER-391:
-
[~cstamas] right, I think the problem in this case is in "how the winner is
selected".
As a developer, I want to make sure my tests are using a classpath that is as
close to the production one as possible. I want to be able to modify it for
tests to add alternative implementations of some services or interfaces - true.
But I want to be in control of that when that happens, by adding those
dependencies as direct dependencies with versions I set explicitly, for example.
Of course, there are tools I can configure and run to make sure I (or rather
the Maven resolver) don't accidentally re-arrange *the production part of my
test classpath* that *I don't expect to be re-arranged* when bumping some
library versions (e.g. following a dependabot updates, etc). I am arguing these
tools should not be needed, they are a workaround for an issue that needs to be
fixed.
[~perdjesk] mentioned
[https://github.com/basepom/maven-plugins/blob/main/dependency-scope/README-hubspot.md.]
Here is a quote from it's readme explaining why it was developed and what it
solves:
{noformat}
This plugin aims to mitigate a particular pesky problem with Maven which is
that if you declare a dependency with test scope, that will take precedence
over a transitive dependency with compile scope.
This plugin attempts to mitigate this problem by verifying that test-scoped
dependencies don't appear elsewhere in your dependency tree at scope runtime or
compile.{noformat}
It's a safety measure. I believe most of the users aren't aware of this issue
until they start running into unexpected behavior in production that they don't
observe in their tests. It's not intuitive and even with the tools that help
with analysis, applying fixes by adding *the original transitive compile
dependency versions* to the dependencyManagement or as direct dependencies is
cumbersome and complicates maintenance of the project from that point on
(basically, until the next round of version updates, since then I'd have to
re-do the analysis by reverting the previous "compensations" in
dependencyManagement and apply a new more relevant one).
> Scope mediation improvements
>
>
> Key: MRESOLVER-391
> URL: https://issues.apache.org/jira/browse/MRESOLVER-391
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope
> "compile" is found deeper in graph, the "test" scope wins. This at runtime
> may lead to CNFEx.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780461#comment-17780461 ] Alexey Loubyansky commented on MRESOLVER-391: - [~cstamas] using the resolver directly, when I resolve a compile or runtime classpath, i would not include direct dependencies with scope test and that would work as expected. But when I want to resolve a test classpath, I will also include direct dependencies with scope test and end up with the tree posted above. As we talked previously, I don't think this should be considered an expected outcome. I mean, knowing the impl details, it is but, imo, it's not the desired result for the majority of users. As a user, I can clearly see my direct dependencies in the POM (hopefully, unless there is a parent hierarchy that contributes to that), what happens deeper though is not evident but I'd like to be sure my runtime classpath doesn't change "randomly" when running tests. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780307#comment-17780307 ] Alexey Loubyansky commented on MRESOLVER-391: - > As such the example is consistent in test and runtime. Not really. The runtime classpath will contain a different version of acme-lib-c (and possibly its dependencies). Imagine there are consumers of acme-product-a, that add acme-product-a as a dependency. Unless acme-product-a includes integration tests, acme-product-a will be tested having acme-lib-c:2.0.0-SNAPSHOT on its test classpath and then packaged up and deployed to Maven. Projects depending on acme-product-a will see that it depends (transitively) on acme-lib-c:1.0.0-SNAPSHOT, although acme-product-a was tested having a different version acme-lib-c on its classpath. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780278#comment-17780278 ] Alexey Loubyansky commented on MRESOLVER-391: - AFAIU, the root cause is the same, which is compile scoped dependencies may be overriden by test, leading to differences between test and runtime classpath, which may lead to all sorts classloading and other issues at runtime, that aren't detected during unit testing phase. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780202#comment-17780202 ] Alexey Loubyansky commented on MRESOLVER-391: - Sure, hope [https://github.com/aloubyansky/playground/tree/test-scope-overriding-compile] would help? Thanks for looking into this [~cstamas] > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770028#comment-17770028 ] Alexey Loubyansky edited comment on MRESOLVER-391 at 9/28/23 12:11 PM: --- I think this should also cover provided scope. Meaning compile and runtime should be preferred over test and provided. In addition to that, it should also *not* be limited to the distance to the root node. If conflicting versions appear to be on the same depth level but the test or provided scoped dependency branch appears before the compile or runtime one, the compile/runtime node should win. was (Author: aloubyansky): I think this should also cover provided scope. In addition to that, it should also not be limited to the distance to the root node but also on the ordering of the dependencies. E.g. if conflicting versions appear to be on the same depth level but the test or provided scoped dependency branch appears before the compile or runtime one. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770028#comment-17770028 ] Alexey Loubyansky commented on MRESOLVER-391: - I think this should also cover provided scope. In addition to that, it should also not be limited to the distance to the root node but also on the ordering of the dependencies. E.g. if conflicting versions appear to be on the same depth level but the test or provided scoped dependency branch appears before the compile or runtime one. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-6922) Introduce a notion of a "project release" as the origin of an artifact
Alexey Loubyansky created MNG-6922: -- Summary: Introduce a notion of a "project release" as the origin of an artifact Key: MNG-6922 URL: https://issues.apache.org/jira/browse/MNG-6922 Project: Maven Issue Type: New Feature Components: Artifacts and Repositories, Dependencies, Design, Patterns & Best Practices Reporter: Alexey Loubyansky The valuable information that I find missing from what is resolvable using the API and/or exposed through the CLI and not taken into account by the version convergence algorithm is the notion of a "project release" that represents the origin of an artifact in a repository. Simply speaking, for any specific artifact version in a repository, I want to be able to find out which other artifacts were a part of the same release. That is if it was a multi module project producing multiple artifacts. Currently, this information is not readily available and not easy to restore. There are clues in the parent POMs, SCM, MANIFEST.MF, other project-specific files. But those are not generally reliable today (given that I want to be able to get that info for any artifact, not only the projects that I release myself). The reason I consider this information being important is that a release is supposed to pass certain quality requirements (tests in various environments, all sorts of compatibility checks, etc). Being able to find a complete set of artifacts that satisfy all those requirements is essential for any provisioning system. There are BOMs, of course. But not every project includes a BOM and in general there is no link between an artifact and a BOM representing the project release. My other point was that I think the Maven version convergence algorithm should not be ignoring this artifact "release origin", given that there is an objective to make the best effort to settle on a set of artifacts that are compatible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
