User Guide: Clarifying overriding of transitive dependencies


(davidmichaelkarr) #1

26.4, “Dependency management”, talks about the transitive behavior of provided dependencies. It uses the example of specifying “commons-httpclient” in a provided configuration, which results in both this and “commons-codec” NOT being included in the WAR file, because “commons-codec” is a dependency of “commons-httpclient”. At the end of the paragraph, it says exactly this:

If you don’t want this transitive behavior, simply declare your provided dependencies like commons-httpclient:commons-httpclient:3.0@jar

With no explanation.

This needs more information. This is implying that simply by adding the “classifier” to the dependency somehow makes this behavior not happen, and I’m not even sure what the resulting behavior would be. Does this mean that commons-codec WOULD be included in the WAR, but commons-httpclient would NOT be? What other information should be provided here?


(Luke Daley) #2

We shouldn’t be recommending the use of explicitly specifying the artifact type (which is what @ is doing, it’s not about classifiers).

Instead, it should recommend the use of ‘{ transitive = false }’ (see DependencyHandler docs).

The point that it’s making is that if ‘commons-codec’ is already in your compile dependencies, and you add ‘commons-httpclient’ to providedCompile, you will get neither httpclient nor codec in your WAR. If you do want codec, then you need to exclude it from the httpclient dependency. You could do this with a targeted exclude, or by declaring httpclient like this:

‘’’ dependencies {

providedCompile “commons-httpclient:commons-httpclient:3.0”, {

transitive = false

} } ‘’’