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 think this is a good thing to aim for.
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.
Both these processes would be good to see.
I imagine we'd need some sort of version information in the usePlugin
statement: usePlugin name: 'helloWorld', version: '1.2+'
That looks suspiciously like a dependency declaration.
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?
It is a good idea. We plan to do something like this, we haven't gotten
to it yet.
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.
There's a couple of things we could do to make this easier:
- Move the 'providedCompile' and 'providedRuntime' to the Java plugin
- Provide some way to declare a dependency on the Gradle API (which may
or may not involve adding it to the central maven repository)
Then you could do something like:
dependencies {
providedCompile name: 'gradle-api' version: '0.8+'
}
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.
I think the above does this. The version constraint from the dependency
on 'gradle-api' would end up in the meta-info for the plugin.
I would also add to your list:
4. Lack of documentation. It is quite easy to create and use plugins,
but nobody knows this, because we haven't documented how to do so.
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
I think we might want a plugin-plugin to take care of most of this.
User perspective:
http://gradle-plugins.appspot.com/user/build.gradle
We would want a convenience method, or plugin, or something, to add the
central plugin repository to the build's repositories.
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
