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)
Example:
project structure:
root
±A
±B
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
StackOverflowError
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 @ https://drive.google.com/file/d/0B6l2d5ZRJhY5S2ZlSDNKa29VTkE/view?usp=sharing
Cheers, Christian
PS: Gradle is still awesome 