Hi,
Am 18.07.2010 um 01:46 schrieb Adam Murdoch:
> 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.
Well, I kind of didn't have a choice. ;] That's the fate of an early adopter. I
could have stayed
> 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
I'm not sure what could be removed. What I need for Clojure are the source
directories (not only the files) from the source sets. So I added that.
Otherwise this part was pretty straight-forward.
> - some ways to extend the test infrastructure to add support for language
> specific test tools
Yeah. This is something I still have to understand. I saw that there is the
idea for different test frameworks, but I'm unsure how to use that, since
things are from api.internal. (And even then, I'm not sure how to integrate
clojure.test.)
> - some shared documentation infrastructure
Again this is something language specific. groovydoc seems quite close to
javadoc, but for clojure there is no standard, yet. Tom Faulhaber's autodoc is
a high ranking candidate, though.
> - some ways to extend the ide integration to add language specific
> configuration to the generated ide files
Ok. I'm a vimmer and a hobbyist. So I can't say much on that one.
> 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.
That would be nice. But that would really be a longer term goal. At the moment
I'm unsure how to keep the style of the plugin. I started by kind of reverse
engineering the Java and the Groovy plugins. But they do a lot of stuff on a
very low-level. Going from 0.8 to 0.9, quite a bit changed in the way they work
(or at least how they look). So instead of understanding everything again, I
nuked the old code and basically did a complete re-write trying to stay as
close to a hypothetical build.gradle as possible. How would I do it manually?
Do the same just iterate over the source sets etc. And I like the new code
more, because it feels more declarative.
> 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.
I changed the uberjar task to depend on jar.source and also use it for the
contents. In theory there might be several Jar tasks with corresponding
Uberjars. Then hard-wiring to the main source set would limit it to the main
jar. I don't know how reasonable that is, but I try to not unnecessarily
introduce restrictions. Hmmm... Maybe uberjar should actually be a rule?
> - Neither the 'deps' or the 'uberjar' task are clojure specific. Perhaps they
> would be better off living in the java plugin.
Feel free to use whatever you think would be useful – be it ideas or even code.
clojuresque itself is MIT licensed. (I'm also happy to provide patches, but I'm
not sure I'm familiar enough with the gradle code base...)
> - 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'
Doh. I need a test suite.
> - 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).
Argh. This is actually a part where I had really problems how to hook into the
system. Theoretically I could use an SSH maven deployer with clojars, but I had
no luck getting it to work, because of some known-but-unfixed bug. Hmm... Maybe
I should check again. And other manual ways of using ssh didn't work besides
the manual shell out via exec. bleh.
Argh again. I really have to borrow a rubber duck from my son. Upload is a
convention task. I can hook into its creation – as I did now – and add a
convention. Then one can do:
uploadArchives {
clojarsDeploy()
}
I can't hook into repositories, because I need to add an action to the task and
there is no way to get the task back from the repositories handler.
Implementation here:
http://bitbucket.org/kotarak/clojuresque/changeset/664fb357eba9
Thanks to you and Levi. That is exactly the feedback I was hoping for!
Sincerely
Meikel
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
