List of configurations, lifecycle and adhoc configurations

Is there a way to get a list of configurations associated with a plugin?

What does dependency configuration inheritance mean? In the guide chapter 23.5 it shows testRuntime inheriance. I thought this might mean that I can add dependencies for testRuntime and have them applied to main and test compile and runtime dependencies. But, that doesn’t seem to be the case. Do I really have to copy the same dependency lists for each configuration?

In the samples there are examples where a configuration is added by naming it in a configurations block, e.g. apiAndImpl. A dependency is then declared for that configuration. What is that doing? How does that allow a compiler to find a dependency, and at what stage? There is an api and an impl source directory, which matches the configuration names. So, does configuration equal directory name?

Let’s see if I understand you correctly. I think the dependency ‘inheritance’ depicted in Figure 23.2 on the Java Plugin gradle user guide page are in the opposite direction from how you are trying to use them.

In other words, if you add a dependency to the ‘compile’ configuration, it will automatically be available in the ‘runtime’ configuration as the runtime configuration extends (or ‘inherits from’) the compile configuration. This makes sense as this is how things normally behave. If we need log4j at compile time, chances are we will need log4j at runtime.

There are ways to change this if needed, but I believe that is the basic idea.

As for adding a new configuration like ‘apiAndImpl’: As far as I understand them, configurations can be seen as abstract ‘buckets of dependencies’ and unless you (or some plugin you are using) are explicitly doing something with each configuration, the only thing that happens after the configurations and dependencies blocks are executed is that you have a new ‘bucket’ which can be accessed via ‘configurations.apiAndImpl’.

You can then use this new configuration in your build files like this:

compileJava {
  classpath = configurations.apiAndImpl
}

which would reconfigure the default java compilation task for the java plugin to use the dependencies defined in the apiAndImpl configuration as the compile classpath, ignoring the default ‘compile’ configuration and its defined dependencies.

Thank you. Yes, I see the inheritance goes the other direction.

What you say about configurations makes sense and it’s what I would expect. But, in the apiAndImpl, I might be seeing something different. It’s not declaring a configuration maybe. It is naming source sets. Then the name of that source set magically becomes associated with apiCompile which is used in a dependency:

sourceSets { api } dependencies { apiCompile ‘blah’ }

and there is the task apiCompile and running task test builds the classes from the java in the api directory.

The documentation about dependencies says that a dependency is associated with a configuration. So, I guess, creating a directory and referring to it by name as a source set, creates a configuration with the same name? It’s taking a while for me to put the pieces together in my head.

Yes, the source set concept is a different animal. Take a look at the Java Plugin page in the user guide where the source set concept is explained at some length.

Essentially the ‘sourceSets { api }’ statement adds a new source set called ‘api’ to your project. Quoting the above java plugin page:

For each source set you add to the project, the Java plugin adds the following compilation tasks:

  • compileSourceSetJava - Compiles the given source set’s Java source files using javac. * processSourceSetResources - Copies the given source set’s resources into the classes directory. * sourceSetClasses - Assembles the given source set’s classes directory.

which is where your extra tasks come from. Further down the page:

For each source set you add to the project, the Java plugins adds the following dependency configurations:

  • sourceSetCompile - Compile time dependencies for the given source set * sourceSetRuntime - Runtime time dependencies for the given source set

which is where the ‘apiCompile’ configuration came from.

I agree, took me a while to get my head around the concepts too. Once there it is quite a powerful model though.