How to exclude a dependency from compile but not from testCompile without reshuffling configuration structure


(Thibault Kruse) #1


I would like to make sure that a dependency like group “org.codehaus.jackson” never gets put onto our compile or runtime classpath. At the same time, I need to have it allowed into our testCompile for one test library.

There is a similar question from the old forum:

But it is not that helpful. Reshuffling configurations causes massive confusion. So is there any other way I can prevent certain transitive dependencies from slipping into production jar, while allowing them in tests?

Also related: the extends from design:

I believe the gradle design is flawed. When one configuration extends from a parent, all dependencies from the parent (after applying exclusion rules) should be added to the child, but the child should be free to add dependencies even when those are excluded from the parent. In case somebody wants to exclude over a hierarchy, that person should do that explicitly by adding an exclude rule to all configurations in the hierarchy. That would keep the current flexibility but still allow reasonably well to add dependencies to tests that are not forbidden at (non-test) runtime. I believe the current design instead leads team to be more permissive (less safe) about what can go into (non-test) runtime, because forbidding certain dependencies becomes a major pain.

A mitigation that is backwards compatible might be to add a localExcludeRules in addition to the excludeRules of a configuration, such that the localExcludeRules do not affect children extending of a parent with localExcludeRules (or at least not after applying those rules to the dependencies of the parent).

(Stefan Oehme) #2

There is a simple solution for your use case: Don’t define your exclude on compile (which is inherited by testCompile), but only exclude it from compileClasspath/runtimeClasspath.

(Thibault Kruse) #3

thanks, seems ok. Not very intuitive, but I don’t mind. Might be good to update the other questions I linked to, too.