On Jul 22, 2009, at 9:57 PM, Pfau, Matthias wrote:
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.
I agree. This will become more and more important. And is already
important today.
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).
Gregory Boissinot is working on a Gradle scaffolding plugin which I
guess should take care also of Gradle plugin development (I guess the
VCS part would be provided on top of it).
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.
This is a good idea.
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.
Yes. This should work this way. The usePlugin construct would also
offer to specify custom repositories to retrieve plugins from. We also
have to think about a good approach for plugin id's. Right now they
are specified in the GRADLE_HOME/plugin.properties files. I think an
approach which works with jar metadata would be much nicer.
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?
Definitely. We have already problems with version conflicts from
different plugins. This is something we need to solve before 1.0. Our
current plan is to use OSGi for this. Tom Eyckmans has already created
a GitHub Gradle branch where he started to work on this. But at the
moment Tom has not time to continue to work on this.
2. A plugin always has to depend on the gradle-api jar.
Unfortunately, this jar is not published to any repository.
We have to do this soon.
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.
I see.
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.
What the plugin could do already is to check the
project.build.gradleVersion property. But I guess it would be a richer
approach if the plugin could provide metadata for this.
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 ?)
Good idea.
* Can the repository be hosted by Codehaus? Or are sponsors needed
for a central repository?
I will check with Codehaus.
* Setup the repository
Just let me know, if I can be of any help.
Thanks a lot for your input. We would very much appreciate your help
on this. First I gonna check out the infrastructure thing.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
