Give a meaningful error message when applying both 'cpp-application' & 'cpp-library' (or java) in a script

[zosrothko]

Hi

When both 'cpp-executable' & 'cpp-library' plugins are applied in a gradle script, the build fails with

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\fandre\Documents\git\gradle\subprojects\docs\src\samples\native-binaries\cpp\build.gradle' line: 3

* What went wrong:
A problem occurred evaluating root project 'cpp'.
> Failed to apply plugin [id 'org.gradle.cpp-library']
   > Could not create an instance of type org.gradle.language.cpp.internal.DefaultCppLibrary_Decorated.
      > Cannot add a configuration with name 'implementation' as a configuration with that name already exists.

How to reproduce this failure
In the script subprojects\docs\src\samples\native-binaries\cpp\build.gradle, replace

apply plugin: 'cpp'

by

apply plugin: 'cpp-executable'
apply plugin: 'cpp-library'

and build the updated script.

[lacasseio]

Thanks for reporting this. The intention is to apply one of the plugins at any time in a project. I rename the title of this issue to add a better error message for this scenario.

[lacasseio]

Consider having the same messaging for java plugins, see #352

[lacasseio]

This is causing enough pain, we should address this now.

[lacasseio]

I ended up going down a rabbit hole last week. The main issue is being able to catch when unwanted plugins are mixed together. Adding code to the plugin itself is a bit hacky and requires to modify all plugins to work. Also, applying the native plugin first then the Java plugin after succeeds given that JVM plugins use maybeCreate when creating new configurations. The opposite fails.

We can focus on just giving an improved messaging for native plugin mixing. Scoping the JVM plugins as well increase the code change and scenario to support. One thought while working on this is the plugin manager should probably take care of this restriction. I think it would nicely fall into the supporting work for improved metadata for plugins such as supported Gradle APIs and such.

The use case we are trying to solve is declaring how plugins interact with each other. I'm not sure how we want to move forward. We could spike this as simply doing code changes to all the affected plugins and ignore any change to the plugin manager or we can lay down the minimal strategic work to improve the error message.

[adammurdoch]

The basic problem here is that multiple plugins are defining a main component, but not all of them declare that they are going to do so. A good fix would take steps towards addressing the basic problem, by adding the smallest amount of infrastructure for a plugin to declare this. This can be just enough to give a better error message. Later this can evolve to do better stuff.

There are 2 approaches we could take:

1. Something statically declared on the plugin, such as an annotation on the plugin type, or a super interface or an annotated method. When validating a plugin prior to application, we can detect conflicts and give good error messages (and later deal with the conflict in better ways, eg by supporting a second outgoing component or have one replace the other as the 'main' component).
2. A service with an API to register a component. Each of the plugins can use this service to register the main component, and the service can fail on conflict (and later deal with the conflict).