On 18/07/10 5:02 AM, Meikel Brandmeyer wrote:
Hi,
I'm developing clojuresque – a Clojure plugin for gradle. I'm searching my way
through the gradle docs, but the documentation on how to write a
more-than-trivial plugin – hmmm – „has potential.“ Also my Groovy-fu is limited
to looking at the gradle sources and this plugin.
So I'd appreciate any feedback on whether I'm on the right track. Note though,
that some features like documentation handling and tests are not implemented,
yet.
The source can be found on bitbucket: http://bitbucket.org/kotarak/clojuresque.
First, let me say that implementing a language plugin for Gradle is
probably the toughest task you could have chosen. So, excellent work
with getting something to actually work.
There's definitely a heap of stuff we can do in Gradle to make it easier
to implement a language plugin. So far, this really hasn't been one of
our priorities. After the 0.9 release, we want to do some work on making
the plugin author's life easier, and we can potentially look at things like:
- reducing the boiler plate required to wire a language into the
compilation tasks
- some ways to extend the test infrastructure to add support for
language specific test tools
- some shared documentation infrastructure
- some ways to extend the ide integration to add language specific
configuration to the generated ide files
Plus, we will continue to flesh out the plugin development documentation.
Longer term, I think it would be nice for the clojuresque plugin to
become an 'official' Gradle plugin, if you'd like. I'm not sure exactly
what that will mean. At this stage it means that the plugin lives in the
Gradle source repository and is released as part of the Gradle
distribution. We ultimately want something more loosely coupled, I
think. Our plan is to end up with a plugin portal which hosts all the
offical plugins (eg java, groovy, maven, eclipse, and so on) plus the
community contributed ones. The goal is to get rid of the differences
between the official plugins and the community contributed ones, so that
a community plugin can easily become an official one (and vice versa),
without needing to change where the source of the plugin lives, or who
develops it, or locking down APIs, or how it is built and released, etc.
Ideally an official plugin will simply be one which is certified to meet
some level of quality - eg is well integrated and consistent with other
plugins, well documented, and so on.
I've had a look through your code. It looks good. Here are a few comments:
- ClojurePlugin.configureUberjar(), line 117: You could use 'from
sourceSets.main.classes' instead of 'from
project.zipTree(jar.archivePath)'. This way, you don't have to build the
Jar in order to build the uberjar. This also mean you can get rid of
'dependsOn jar' from line 108.
- Neither the 'deps' or the 'uberjar' task are clojure specific. Perhaps
they would be better off living in the java plugin.
- I think there's a bug in ClojureSourceTask.includeNamespace() and
excludeNamespace(). They both refer to a property called 'patter'. I
think that should be 'pattern'
- Ultimately, the code that ClojurePlugin.configureClojarsUpload()
applies to each Upload task might be better done as a repository
implementation. This way, it can be explicitly applied to the
appropriate Upload tasks. For example, I don't want to have the
'install' task, which is of type Upload, upload my jars to the clojars
repository. I wouldn't try to provide a repository implementation until
we rework the repository API after the 0.9 release (because if you do it
now, you would have to implement the Ivy Resolver interface).
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
