Cannot extend from a configuration of another sub project

Hi, I recently stumbled upon the implementation changes which now allow you to extend a configuration from another (sub) project. This is particular useful if you want to inherit all the testCompile dependencies (e.g. when having a spring context which is packed as a ‘tests’ artifact, or even if you try to inherit a ‘providedCompile’ configuration which contains artifacts to be excluded upon 'war’ing)


project structure:




Now, let’s say in A we define a new configuration called ‘providedCompile’ which contains artifact which are provided by an application container (e.g. a JEE compliant app server). Let’s now assume ‘B’ contains some fancy services which depend on A and which will be 'war’ed later. The ‘war’ plugin introduces a convention that ‘providedCompile’-dependencies will not be included into the library folder. So far so good. Now as I want to inherit all those ‘provided’ dependencies in B’s scope, I do not want to write some code which copies the dependencies there, because with multiple layers this is cryptic and also not very declarative.

Now what I did was writing:

configurations {

providedCompile.extendsFrom project(’:A’).configurations.providedCompile

} Which would be the gradle way to express what I was just writing about. When running a

gradle B:dependencies I will get a


I have analyzed the problem further and I believe I have found the source of it. In AbstractModuleDescriptorBackedMetaData the configuration name is used to gather all the configurations in the hierarchy. Well in case of a Configuration of another’s project this is simply not enough and the loop will either - run indefinitely - if the project the resolution is run on, contains a configuration with the very same name (which is the case with in example) - stops with a NPE - in the other case (since the configuration cannot be found

You can grab my example @

Cheers, Christian

PS: Gradle is still awesome :slight_smile:

Okay, I just had a deeper look into it. And since the resolution will become more difficult in th eAbstractModuleDescriptorBackedMetaData (since that thing is written with the thought in mind, that the configuration is always from the same module), it seems this is certainly not the point to start from. Probably a good ways would be handle configuration extends from other project either never (re add that check from a previous version), or inherit those dependencies in another way (like copying them before resolving or sth in DefaultConfiguration).

I started fixing the issue and added a pull request (Also signed that agreement). :slight_smile: Still I fear I should implement further tests (though the check results came up positive). How can I get in contact with a dev?