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
There’s a good chance something like that could work, if you hadn’t tried it yet.
Please let us know if it does or not? Thanks.
EDIT: Actually, I see that you have tried something similar before…
Have you tried it with the class literal (.class) of the plugin you want to apply? Like it’s done in the Gradle source links? Instead of the plugin’s id string?
Did anyone end up getting this working? I’m also trying to get this working but have had issues (the plugins are actually in completely different repos that I’m trying to incorporate)
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.
Does that mean I cannot dynamically choose a version for the 3rd party plugin I want to apply? I would like the user’s configuration (maybe indirectly) to affect the version of the plugin I will apply from my plugin. How can I do that?
There is very VERY shady way to do that by hacking the settings ClassLoaderScope, but I’d rather not…
The user could use a dependency constraint in the buildscript { ... } block to influence the version, or you could require the user to add the plugin in the wanted version to the buildscritp’s classpath.
The user might not be directly controlling the version of the plugin, for instance it might be that enabling some features leads to some different choice of version. But I have to admit my case is unorthodox.
I see. If this is more like an A or B situation than a 1 out of 100 situation, it might maybe be feasible to release two variants of your plugin instead of having some feature switch.