Closed jnehlmeier closed 6 years ago
ReckonPlugin.ID
would also be useful.
Thanks for the report! I'll plan to include this in 0.8.
I have constants for the task names, so I'll make them public. As for the plugin ID, I'd suggest referencing the plugin class instead. (i.e. project.getPlugins().apply(ReckonPlugin.class)
.
The ID is useful for PluginManager.findPlugin(id) / hasPlugin(id) / withPlugin(id, action)
. Especially the last one for "reactive plugins" that do stuff if a different plugin is active.
https://docs.gradle.org/current/dsl/org.gradle.api.plugins.PluginManager.html
You should be able to get the same functionality from:
project.getPlugins().withType(ReckonPlugin) {
// logic here
}
Personally, I just hardcode the strings in a withId
when I am doing reactive plugin stuff. Usually when I'm writing reactive plugins, I don't want a compile dependency on the plugin anyway, so using a constant won't work anyway.
You should be able to get the same functionality from:
project.getPlugins().withType(ReckonPlugin) { // logic here }
Yes, although documentation says, it is recommend to use project.getPluginManager()
or plugin related methods on project / PluginAware
itself (e.g. apply()
). So no withType
method available if you stick to it.
Personally, I just hardcode the strings in a withId when I am doing reactive plugin stuff. Usually when I'm writing reactive plugins, I don't want a compile dependency on the plugin anyway, so using a constant won't work anyway.
True, in my case I have a plugin that applies reckon automatically and then configures it. So I have that dependency anyways. Using constants just feels a bit more natural then.
If you're already directly applying the plugin, you won't get any reactivity out of withId
. Any code after the apply can rely on the plugin's behavior being in place.
Since plugin IDs are specified external to the code, in a properties file, a constant wouldn't ensure it matches the actual ID. I don't recall seeing constants used for plugin IDs in any other plugins I've read through.
When writing Gradle plugins that try to pre-configure something, it is useful to have public constants for task names available.