[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780907#comment-17780907
]
Alexey Loubyansky commented on MRESOLVER-391:
---------------------------------------------
[~cstamas] right, I think the problem in this case is in "how the winner is
selected".
As a developer, I want to make sure my tests are using a classpath that is as
close to the production one as possible. I want to be able to modify it for
tests to add alternative implementations of some services or interfaces - true.
But I want to be in control of that when that happens, by adding those
dependencies as direct dependencies with versions I set explicitly, for example.
Of course, there are tools I can configure and run to make sure I (or rather
the Maven resolver) don't accidentally re-arrange *the production part of my
test classpath* that *I don't expect to be re-arranged* when bumping some
library versions (e.g. following a dependabot updates, etc). I am arguing these
tools should not be needed, they are a workaround for an issue that needs to be
fixed.
[~perdjesk] mentioned
[https://github.com/basepom/maven-plugins/blob/main/dependency-scope/README-hubspot.md.]
Here is a quote from it's readme explaining why it was developed and what it
solves:
{noformat}
This plugin aims to mitigate a particular pesky problem with Maven which is
that if you declare a dependency with test scope, that will take precedence
over a transitive dependency with compile scope.
<skip>
This plugin attempts to mitigate this problem by verifying that test-scoped
dependencies don't appear elsewhere in your dependency tree at scope runtime or
compile.{noformat}
It's a safety measure. I believe most of the users aren't aware of this issue
until they start running into unexpected behavior in production that they don't
observe in their tests. It's not intuitive and even with the tools that help
with analysis, applying fixes by adding *the original transitive compile
dependency versions* to the dependencyManagement or as direct dependencies is
cumbersome and complicates maintenance of the project from that point on
(basically, until the next round of version updates, since then I'd have to
re-do the analysis by reverting the previous "compensations" in
dependencyManagement and apply a new more relevant one).
> 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)
