[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832262#comment-17832262
]
Henning Schmiedehausen commented on MRESOLVER-391:
--------------------------------------------------
If the problem described in MNG-8041 can not be fixed for Maven 3/4 for
backwards compatibility, wouldn't it be possible to have a flag or config
option in the pom where my project can "opt in" to the correct/new behavior?
The challenge with "being backwards compatible at any cost" means that there is
no progress.
I am totally willing to test-drive/fix my builds if a change breaks it, if I
can *opt into* the change at my own pace and don't get it forced on me.
If this is a property that one can set in the pom
(`<maven.core.resolver-behavior>legacy|modern|</maven.core.resolver-behavior>`),
I am sure that a lot of projects would want to try this out/adopt it. Right
now, we all do various workarounds to keep our builds working and would love to
get rid of the rather sooner than later, even if that means to rewrite my
builds. Thanks to the maven wrapper, I can ship a "working maven version" with
my project so I no longer need to care about "what version of maven the user
has installed".
Please consider having an optional "here is the full fix, expect things to
break, you can activate it with this flag" option for maven 3 and 4. (and
please make it part of the pom, not a command line option :) )
> 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)
