[jira] [Commented] (MRESOLVER-391) Scope mediation improvements

["Henning Schmiedehausen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812532#comment-17812532 ] 

Henning Schmiedehausen commented on MRESOLVER-391:
--------------------------------------------------

(got pinged from here: [https://github.com/basepom/maven-plugins/issues/9)]

 

These are the use cases that I keep running into:

 

I have a project using depA in compile scope. depA has a transitive dependency on depB. 

=> I expect depA and depB to be on compile, test and runtime path

I have a project using depA in compile scope and depB in test scope. depA has a transitive dependency on depB

=> I expect depA and depB to be on compile, test and runtime path

 

I have a project that has a runtime dependency on depA

=> I expect depA to be on the runtime path, but not compile or test

But now I write a test that needs depA as well. How can I express a dependency in test *AND* runtime scope, but *NOT* compile scope???

 

Both are very common in my world.

 

 

 

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