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
signature.asc
Description: OpenPGP digital signature
