As a workaround you can check out the dependency-scope-maven-plugin we wrote: https://github.com/HubSpot/dependency-scope-maven-plugin
The initial motivation was avoiding NoClassDefFoundError when someone accidentally puts a dep at test scope that is transitively required at runtime. I made a pom with the example dependencies you gave: https://gist.github.com/jhaber/19d0b0a0454a6f05fde3375b21b8447e And the plugin correctly failed the build: [INFO] --- dependency-scope-maven-plugin:0.8:check (default) @ test --- [ERROR] Found a problem with test-scoped dependency org.hamcrest:hamcrest-core Scope compile was expected by artifact: junit:junit:4.9 [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ On Thu, Nov 23, 2017 at 2:16 PM Robert Scholte <[email protected]> wrote: > 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] > >
