but when the consumer uses this plugin it raises an error
FAILURE: Build failed with an exception.
Build file '/Users/andreas/eclipse-workspace/tester/build.gradle' line: 12
* What went wrong:
An exception occurred applying plugin request [id: 'com.bisiach.gradle.custom-plugin', version: '1.0.0']
> Failed to apply plugin [id 'com.bisiach.gradle.custom-plugin']
> Cannot change dependencies of configuration ':classpath' after it has been resolved.
Unfortunately I discovered the neither my approach or the one in the guide work.
I will use the terminology in the guide to be more clear.
In my scenario the Base Plugin (the capability plugin) is published public here:
On the other hand, the “convention” plugin will be published privately to a company maven repo. The plugin named i.e: com.acme.gradle.standard-development-plugin.
The idea is that this plug-in will be applied to all customer projects using gradle.init.
During develompent, to test com.acme.gradle.standard-development-plugin I am using composite build.
I have a project “test” that includes the build of com.acme.gradle.standard-development-plugin. In this scenario, adding the following to build.gradle of com.acme.gradle.standard-development-plugin worked. but only because in a composite build, the project “test” can see the runtime dependency:
After publishing my com.acme.gradle.standard-development-plugin to an internal maven repo, and including in the project “test” as a normal plugin, the plug in fails to apply the base (capability) plugin com.bisiach.gradle.gitversion-plugin.
The examples outlined in the guide always shoes capability and convention plugins coming from the same gradle build. That is why it works there I think.
I need to achieve the same between 2 plugins coming from 2 different builds/repositories
The Issue with the above mentioned solutions is that they declared the dependency in the plugins build.gradle file as runtime. That’s why you can not apply the Plugin class (as it is missing in the compile classpath). Just change the dependency to implementation.
I don’t think that any lazy configuration will help here as one usually wants to interact with the other plugins datastructures and therefor you’ll need access to the classes on the compileClasspath and runtimeClasspath what the implementation configuration is meant for.
Well this is by design. Even when doing it from inside your convinience plugin you technically do write apply plugin: 'includedPluginId' and this will add all Tasks, Configurations etc. to your project and thus it’s namespace. I’m pretty sure this is intentional and can not be avoided.