[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786310#comment-17786310
]
Tamas Cservenak edited comment on MRESOLVER-391 at 11/15/23 10:56 AM:
----------------------------------------------------------------------
Well, let me lay down first few things:
* resolver does not "manipulate" anything, all it does is following the user
authored input (it will not "come up out of the blue" with some dependency, it
is user who is laying down those test scoped dependencies and resolver just
obeys them).
* resolver, whatever tree it resolves (runtime or test) always works in "maven
way": dependency being closer to the root "wins". There is no weighing or
prioritization (well, "depth" is priority in this case, one could say).
* I have a feeling you want something like (just for example sake, very broadly
spoken) "xml xpath" is? Like, you have a huge graph, and then like a surgical
"scalpel" alter some nodes?
As for current time, yes, user should use "managed dependencies" and probably
comment well why this or that was added. But, lately BOM-like dependencies
became over-used (for my taste) and they started to form hierarchies (BOM
imports BOM that imports...), while users are NOT fully aware of "POM import"
(BOM) _differences_ when compared to "maven way" (issue
https://issues.apache.org/jira/browse/MNG-7906), but this is purely Maven issue
and not related to Resolver.
was (Author: cstamas):
Well, let me lay down first few things:
* resolver does not "manipulate" anything, all it does is following the user
authored input (it will not "come up out of the blue" with some dependency, it
is user who is laying down those test scoped dependencies and resolver just
obeys them).
* resolver, whatever tree it resolves (runtime or test) always works in "maven
way": dependency being closer to the root "wins". There is no weighing or
prioritization (well, "depth" is priority in this case, one could say).
* I have a feeling you want something like (just for example sake, very broadly
spoken) "xml xpath" is? Like, you have a huge graph, and then like a surgical
"scalpel" alter some nodes?
As for current time, yes, user should use "managed dependencies" and probably
comment well why this or that was added. But, lately BOM-like dependencies
became over-used (for my taste) and they started to form hierarchies (BOM
imports BOM that imports...), while users are NOT fully aware of "POM import"
(BOM) _differences_ when compared to "maven way" (issue
https://issues.apache.org/jira/browse/MNG-7906)
> 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)
