Re: Dependency scopes and conflict resolution: Possible bug?
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.
On Thu, 23 Nov 2017 09:49:50 +0100, Andreas Sewe
<[hidden email]> 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:
>> <!-- compile-depends on org.hamcrest:hamcrest-core:1.1 -->
> 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,
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]