ajoberstar / reckon

Infer a project's version from your Git repository.
Apache License 2.0
190 stars 28 forks source link

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

Closed jnehlmeier closed 6 years ago

jnehlmeier commented 6 years ago

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 commented 6 years ago

ReckonPlugin.ID would also be useful.

ajoberstar commented 6 years ago

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

ajoberstar commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.