[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832265#comment-17832265
]
Tamas Cservenak commented on MRESOLVER-391:
-------------------------------------------
Comparison how m-dep-p (affected by Maven Core bug MNG-8041) and Toolbox behave
on reproducer for MNG-8041: https://github.com/cstamas/MNG-8041
https://gist.github.com/cstamas/26c6f3de0770a9b8ebe380e103b9d1ba
> 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
>
> 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)
