[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786342#comment-17786342
]
Tamas Cservenak commented on MRESOLVER-391:
-------------------------------------------
Created m-assembly-p IT that demonstrates the issue (and same stands for
m-dependency-p): https://issues.apache.org/jira/browse/MASSEMBLY-1008 (see PR)
All these plugins are kinda neglected, and their code base seems (is my
assumption) comes from Maven2 times, where it WAS true that "test graph is
superset of runtime graph", but that is not true since introduction of Resolver
(Maven 3.0).
[~aloubyansky] re change, I had some similar experiments in Maven plugin realms
(so not really your use case) that proved quite good (but remained at PoC level
due other issues): https://github.com/apache/maven/pull/1188 The idea here was
that Maven (a "host") resolving plugin (a "guest" coming into host) become more
precisely augmented... basically making Maven "self aware" (aware of it's own
constituents) and augment the plugin resolution to prevent resolving things
that are anyway provided by Maven Core for plugins at runtime. This changed DID
NOT alter end result, in a way, it did not provide different plugin classpath,
it was merely an attempt to solve "maven downloads whole universe" stigma
:smile:, as what today happens is that Maven 3 downloads everything plugin
declares, and then the provided bits are simply ignored (and replaced with core
provided ones). Basically, this was attempt to improve plugin resolution time,
bandwidth usage, etc. Again, this is NOT what you are looking for, but I am
writing this just maybe to provide some idea and maybe sparkle some idea from
your end as well.
> 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)
