https://gradle.com/ logo
Join Slack
Powered by
I'm reading this <documentation paragraph> about r...
# plugin-development
s
I'm reading this documentation paragraph about reacting to plugins inside a plugin, but I have a question: in my case I do need to have a plugin applied so that my plugin works, so I call 
project.getPlugins().apply()
within the plugin's 
apply
method. At the same time, if I apply this custom plugin to more than a project I'm starting to get weird errors that seem to be related to having the plugin applied twice. What would be the most idiomatic approach here? Check if the plugin is already present before applying it or anything else?
v
Besides that you should use 
project.apply()
(read the JavaDoc of 
getPlugins()
, applying a plugin multiple times is the idiomatic way, because the 2nd and further attempts to apply the same plugin are no-ops. So whatever unspecified "weird errors" you have, it is quite unlikely that they are related to the pure multi-application.
So yeah, the idiomatic approach is, if your plugin does something if the other plugin is applied but not if not, then use 
project.pluginManager.withPlugin
, if your plugin requires that other plugin to be applied too, apply it.
s
umm ok let me do a few tests more
👌 1
umm alright, this is a true head scratcher. I'm posting it here but it seems very specific to the plugins I'm using so if you can't help all good. So with this plugin setup
Copy code
`java-library`
id("my.custom.plugin") 
alias(libs.plugins.protobuf)
alias(libs.plugins.python) // also applied in the custom plugin
I get this error
Copy code
Cannot set the value of task ':grpc:stub:python:checkPython' property 'envService' of type ru.vyarus.gradle.plugin.python.service.EnvService using a provider of type ru.vyarus.gradle.plugin.python.service.EnvService.
Which already doesn't make much sense to me as an error. But even more puzzling, if I remove the protobuf plugin then everything works again 🤔
also, the custom plugin is applied to another subproject. If I remove the subproject from the build then the grpc suproject works again even with the protobuf plugin applied
v
That's a classpath problem. Add 
alias(libs.plugins.python) apply false
to the root project and the issue will be gone.
s
man you saved my day. And probably week and month too 😅
👌 1
v
By applying it in the two sibling projects but not having the plugin in a common class loader, the plugin classes are not the same as they come from different class loaders. But the Python plugin is using a shared build service across all projects where it is applied that it gets by name. Unfortunately the type is not correct as one of the plugins registers the services with the class from one classloader, and the other plugin then cannot handle that as the class is a different one even if it has the same FQCN. So if you need the plugin in multiple projects, you need to ensure it is in a common classloader, like adding to the root buildscript classpath, or the settings script classpath, or as 
buildSrc
dependency, ...
s
oh ok yeah that's not very intuitive but it definitely makes sense from a technical standpoint. I still don't know why the issue with enabling/disabling the protobuf plugin tho
v
oh ok yeah that's not very intuitive but it definitely makes sense from a technical standpoint
https://github.com/gradle/gradle/issues/30274 :-)
I still don't know why the issue with enabling/disabling the protobuf plugin tho
Maybe a red herring. Maybe the protobuf plugin breaks task configuration avoidance and it would have failed later anyway if you executed the "right" task. Maybe not, hard to say without stacktrace and analyzing what happens exactly why.
❤️ 1
s
yeah your guess seems reasonable though. Anyway, thanks a million again!
👌 1
@Vampire btw, related to this conversation, this is in the official docs for 8.10:
Copy code
import org.gradle.api.Plugin;
import org.gradle.api.Project;

public class MyPlugin implements Plugin<Project> {
    public void apply(Project project) {
        project.getPlugins().apply(MyBasePlugin.class);

        // define conventions
    }
}
Maybe something to update with a more suitable call chain?
v
Definitely, you should open a doc-improvement issue on GitHub 🙂
👍 1
You did not create one yet, did you? (No need to if you did not yet)
s
No sorry hectic days. I wanted to do it tonight though, you taking care of it otherwise?
v
s
Thanks
👌 1
7 Views
Open in Slack
PreviousNext
Powered by