[
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
> 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)
