I can imagine a plugin to generate the plugin-descriptor. This plugin would allow to write plugins without having to maintain the plugin.properties file in META-INF/gradle-plugins.
If this plugin would also add compile dependencies to gradleApi() and localGroovy(), the minimal build.gradle of a plugin build would just be
apply plugin: 'gradle-plugin'
I am currently thinking about building a prototype of such a plugin. But unless this plugin is part of gradle, the above would also need a buildscript-block with entries for repositories and dependencies. Therefore I would suggest adding this functionality to the bundled plugins.
My first implementation will not do any classloading, but will only do convention-based generation.
All .class files in the classes folder ending with Plugin.class and not beginning with Abstract will be considered. - For the plugin-name, the first char is converted to lowercase, all subsequent uppercase characters are replaced by the lowercase character with prefix ‘-’
Example:
AbstractFooPlugin will not be processed - FooBarPlugin will result in a file META-INF/gradle-plugins/foo-bar.properties
Hello Tobias, we have plans to make the initial setup of a gradle-plugin easier in the future. As part of the incubating build-init plugin we would like to offer an init type “gradle-plugin” that creates a gradle plugin project including a plugin class, plugin descriptor and skeletons for testing the plugin. We track our ideas / implementation plans for the build-init stuff in the according design document in the gradle github repo (https://github.com/gradle/gradle/blob/master/design-docs/build-initialisation.md#story-add-further-project-types). We also looking forward to pull-requests in that area!
Anyhow, in the meantime I created https://github.com/tschulte/gradle-gradle-plugin-plugin. (Sorry for the name, but the convention seems to be gradle-${plugin-name}-plugin. And the plugin name is gradle-plugin–And I found the project-name cool.)
I like the idea of a plugin plugin, I’m working on one myself. Concerning generation of the descriptors, I think it’s too heavy handed. It’s not too hard to write by hand, and there’s too many times where it would have to be customized. Your own plugin is an example where there could be a conflict in the plugin name, i.e. gradle-plugin is pretty generic. I guess I can see that someone could alter their class name to avoid a conflict, but I find people are pretty particular about their class names.
Agreed. But the document is a living spec, means everybody is invited to spec out some details or start discussing on the dev list. You’re right, some of the items listed in the document are just placeholders atm and definitely need more details covered before we can start the implementation
you are right, that there might be some people, who don’t want their classes to be named according to the rules of my plugin. And you are right as well, that it is not that much effort to write the descriptor by hand. And if the build init plugin can handle the generation later on, even better. But on the other hand, the hand written descriptor is a source for error.
But on the other hand I am a lazy bone and I don’t want to mess with more files than necessary. And some well defined conventions are not bad either. If I want to look at the source of the java plugin, and just can search for a class JavaPlugin.(groovy|java), I think that is very nice.
I had a look at some plugins, and the established conventions – I don’t know if this is written down anywhere – seems to be