Just to document a suggestion I made in person at JavaOne:
Consider allowing multiple plugins to supplement the definition of configurations defined by other plugins. For example, I want to use a standard set of configurations, e.g., “compile”, “runtime”, etc. I’m writing custom plugins that would like to contribute additional artifacts to the ones defined by the Java plugin, but can’t.
There are a number of ways to solve this. The easiest, though perhaps not the best, is to change the “add” method to take into account previously added artifacts.
Hmm, I think I don’t understand the use case entirely. We do have plugins that leverage the configurations added by other plugins. For example, ide plugins (eclipse and idea) will use compile, testCompile, etc. configurations only if java plugin is also applied.
This issue came up specifically when I was using the ‘java’ plugin and writing a new plugin that tried to add artifacts to the “runtime” configuration. I couldn’t add anything to the “runtime” configuration because it was already defined by ‘java’ plugin.
That “if” logic is missing from the ‘java’ plugin. I think it should be baked into the interface and not up to each plugin to have that logic.
Here’s my take on it: 1. Gradle plugins (e.g. Java) won’t check for existing of configuration names before adding them. That means that if “runtime” configuration is already created by the time Java plugin applied, it will fail. 2. Java plugin reserves some generic configuration names for Java related stuff, e.g. “runtime” - implying “runtime classpath”. 3. In some usecases (e.g. Mark’s) there are other “runtime” configurations, not particularly related to classpath or Java. Custom plugin would like to use that name. 4. Sometimes that plugin is used in conjunction with Java plugin.That means that it can’t use the term “runtime” in configuration name without clashing with Java plugin.