You're hitting MNG-5739
Within a dependency-tree a groupId+artifactId is unique (nearest wins).
Such a dependency has 1 version, but also 1 scope.
By setting it explicit to test, you reduce the scope and it is not
available during compile anymore.
Is this correct?
Well, this concept ensures that you test with exactly the same set of
dependencies as the ones available at runtime.
On the other hand, reducing the scope implies that you'll be missing one
or more dependencies at runtime.
We could think of making dependencies *always* scope-context-aware.
Using your case one could suggest that at compile-time hamcrest-core:1.1
is used, but at test-time hamcrest-core:1.2
To me this makes more sense, but at the same time it is hard to predict
the impact of such a change.
thanks,
Robert
[1] https://issues.apache.org/jira/browse/MNG-5739
On Thu, 23 Nov 2017 09:49:50 +0100, Andreas Sewe
<[email protected]> wrote:
Hi Maven developers,
I a trying to wrap my head around Maven's handling of dependency scopes
and was wondering the following: Is the test-classpath always a
super-sequence of the compile-classpath?
AFAICT, this is the case. However, my experiments (using Maven 3.5.2)
left me wondering whether I may have stumbled upon a bug.
My (somewhat contrived) scenario is this:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>compile</scope>
<!-- compile-depends on org.hamcrest:hamcrest-core:1.1 -->
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>1.2</version>
<scope>test</scope>
</dependency>
</dependencies>
The *test* classpath that compiler:testCompile sees is junit:junit:4.9 +
org.hamcrest:hamcrest-core:1.2. This is as expected, as the direct
hamcrest-core dependency beats the transitive one; hence, version 1.2
gets picked.
Now, the *compile* classpath that compile:compile sees is just
junit:junit:4.9. While this affirms my super-sequence hypothesis, it
seems like a bug: Without the direct, test-scoped
org.hamcrest:hamcrest-core:1.2 dependency the compile classpath would
have been junit:junit:4.9 + org.hamcrest:hamcrest-core:1.1, but with it
hamcrest-core has vanished completely.
Do you consider this a bug as well?
If so, what's the desired behavior here?
1. A compile classpath of junit:junit:4.9 +
org.hamcrest:hamcrest-core:1.1 would be confusing, as the super-sequence
assumption seems very natural.
2. But a compile classpath of junit:junit:4.9 +
org.hamcrest:hamcrest-core:1.2 seems harder to implement (to my as a
maven-resolver layman, at least), because a pruned part of the
dependency graph may now still exert influence on the versions in other
parts of the graph.
Best wishes,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
