[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780348#comment-17780348
]
perdjesk commented on MRESOLVER-391:
------------------------------------
The current ticket focus on CNFEx within the boundary of one application using
maven.
Within the boundaries of your previous example there should a case in which
acme-product-a application trigger CNFEx when running runtime but not during
tests. For that case (i.e CNFEx) to happen within the boundary of your example
a change must be added so that a transitive dependency which is required at
runtime is overridden with test scope.
This matches this ticket and the related ones described here
https://issues.apache.org/jira/browse/MNG-5988 and
https://issues.apache.org/jira/browse/MNG-4156
What you are describing goes even further and relates to not only scope
mediation but version mediation and both of them together.
{quote}acme-product-a will be tested having acme-lib-c:2.0.0-SNAPSHOT on its
test classpath and then packaged up and deployed to Maven. Projects depending
on acme-product-a will see that it depends (transitively) on
acme-lib-c:1.0.0-SNAPSHOT, although acme-product-a was tested having a
different version acme-lib-c on its classpath.
{quote}
What is described here is mostly related to version mediation and not scope
mediation. The exact same is true regardless of the scope used, as it relates
to version mediation of a similar dependency regardless of scope.
{quote}Projects depending on acme-product-a will see that it depends
(transitively) on acme-lib-c:1.0.0-SNAPSHOT,
{quote}
Consumer of acme-product-a will see all the dependencies (i.e. acme-lib-c:1.0.0
and acme-lib-c:2.0.0) (through pom.xml) and this regardless on how the
dependency mediation was done within the boundary of acme-product-a testing and
building. Consumer of acme-product-a will have their own dependency mediation
on the full dependency graph and thus depending on the consumer's others
dependencies either acme-lib-c:1.0.0 or acme-lib-c:2.0.0 will be selected in
their context. In the case the consumer dependency graph only contains
acme-lib-c through acme-product-a, then acme-lib-c:2.0.0 should be selected.
In the case more control is wanted on dependencies used by upstream consumer
then it is required to use shading over dependencies.
[https://maven.apache.org/plugins/maven-shade-plugin/]
What I get from your example is that you suggest that version mediation of the
same dependency should be "aware" of the scope and selects the version based on
a preferred path only including compile scope instead of test scope.
Preventing CNFEx within one application between test and runtime and the case
you described about upstream consumers and their dependency mediation are two
different things.
> 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
>
>
> 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 message was sent by Atlassian Jira
(v8.20.10#820010)
