Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
3.5.4
-
None
-
None
Description
This is a placeholder ticket for the still existing but not resolved issue MNG-4156 which unfortunately got closed by the 2014 JIRA cleanup.
Original description: "Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. In this case (local test scoped vs transitive compile scoped dependency), requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it's correct in far less cases than it is wrong)."
There exists a plugin that tries to help you to workaround the issue https://github.com/HubSpot/dependency-scope-maven-plugin It also has a very good explanation of the problem:
_"If you declare a dependency with test scope, that will take precedence over a transitive dependency with compile scope. For example, let's say I only use Guava in test code for my project. So it is natural to define a dependency on Guava with <scope>test</scope>. But if any of my dependencies rely on Guava at runtime, my app will now fail at runtime with confusing NoClassDefFoundErrors for Guava classes. So I should just use compile scope for Guava then? Well, if none of your dependencies use Guava at runtime then you've just unnecessarily bloated your app. So I should check my dependency tree for a transitive dependency on Guava and use compile scope if that exists and test scope otherwise? Sure, but you need to repeat this process every time you want to add a test-scoped dependency, and need to reevaluate all previous decisions any time your dependency tree changes. And to make matters worse, the dependency is on the classpath at test time so no amount of unit testing can catch this class of errors.
"_