Hi together, some weeks ago, I asked whether there are any conventions for developing and uploading gradle plugins. Unfortunately, nobody responded, which made me think about the topic (I think Russel posted sth. into this direction, too). Gradle seems to be superior to other software configuration management tools, but one thing which becomes more and more important while gradle itself is splitted into well defined parts is a working plugin/extension community. Projects like Eclipse are famous for their extensibility and they gain a lot from good plugins. This is basically a proposal for building up a plugin community.
The following user stories outline this vision: Developer perspective: As a developer, I want to use my codehaus jira-account to login to gradle.org and create a new plugin (helloWorld). I therefore provide the group and plugin names. The system should prepare a version control system for me, this includes scaffolding of the basic plugin structure (creating directories and a build.gradle). Later, I check out from the prepared repository and implement the plugin. When I am done, I excute 'gradle uploadArchives' and my new helloWorld plugin will be published to the central gradle plugin repository. User perspective: As a user, I want to browse and search through all gradle plugins that are available from the central repository. I want to comment on them and rate them. Actually, I decided to use this new helloWorld plugin. I therefore just want to add 'usePlugin(helloWorld)' to my build script. Gradle takes care of the rest which means, that it downloads the plugin from the central repository. This target does not seem to be far away. However, when I played around, I fell into the following traps: 1. The plugin classloader is based on all libraries that come with gradle. One example for when this causes problems is if you try to write a plugin based on groovy 1.6 and try to use it with a gradle release that still uses groovy 1.5. Woul it be a good idea to provide a "fresh" classloader to every plugin? 2. A plugin always has to depend on the gradle-api jar. Unfortunately, this jar is not published to any repository. To make the plugin compile, I added a flat file repository to the libs folder of gradle. The dependencies to gradle-libs shouldn't be visible for the plugin (because they are already loaded by the classloader). That is why you have to create a custom configuration and publish that artifact with that custom configuration. 3. It is currently not possible to bind a plugin to a specific gradle release. This leads to problems, when the API of gradle changes. The following is a description of what I came up with: * repository at http://gradle-plugins.appspot.com/: This is only for playing around! * small plugin-development plugin See here for an example build-files (developer perspective): http://gradle-plugins.appspot.com/developer/build.gradle User perspective: http://gradle-plugins.appspot.com/user/build.gradle The next steps to address should be: * Decide on central repository location (http://repository.gradle.org ?) * Can the repository be hosted by Codehaus? Or are sponsors needed for a central repository? * Setup the repository Just let me know, if I can be of any help. Kind regards, Matthias --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
