Re: Dependency scopes and conflict resolution: Possible bug?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Dependency scopes and conflict resolution: Possible bug?

Robert Scholte-8
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:
>>   <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: [hidden email]
For additional commands, e-mail: [hidden email]