Make constants for task names public for use in other Gradle plugins

[jnehlmeier]

When writing Gradle plugins that try to pre-configure something, it is useful to have public constants for task names available.

rootProject.getAllprojects().forEach(prj -> {
  TaskCollection<Task> checkTasks = prj.getTasks().matching(t -> {
    return "check".equals(t.getName());
  });
  // currently
  target.getTasks().getByName("reckonTagCreate").dependsOn(checkTasks);
  // better
  target.getTasks().getByName(ReckonPlugin.TAG_CREATE_TASK).dependsOn(checkTasks);
});

[jnehlmeier]

ReckonPlugin.ID would also be useful.

[ajoberstar]

Thanks for the report! I'll plan to include this in 0.8.

[ajoberstar]

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).

[jnehlmeier]

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

[ajoberstar]

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.

[jnehlmeier]

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.

[ajoberstar]

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.