On 24/02/10 9:19 AM, Paul Speed wrote:
Off and on, I'm toying with turning my website tasks into a plug-in.
So far, everything has been in just a special .gradle file but it may
expand beyond that... and I started wondering about specific
deployment models. Plus, my notes may eventually evolve into
something that might help others.
Forgive me if this is all documented somewhere but I couldn't find it
on quick searching...
Currently, (I think) the current methods are:
1) apply url:'http://someplace.online/plugin.gradle', the simplest and
most straight-forward approach... though my guess is that it will
download from the web every time.
It will be, at this stage (it's just the first cut of this). I've added
http://jira.codehaus.org/browse/GRADLE-835 for Gradle to cache
downloaded scripts where it can. And also to deal with offline building
in some useful way.
2) download that plugin.gradle, stick it in my local file system
somewhere and use: apply ur:'path-to-fild/plugin.gradle' Simple enough.
3) package up plug-ins in a jar with a
META-INF/gradle-plugins.properties of some format (I haven't found
obvious documentation for this yet)
The properties file is optional, and is still pretty much an internal
file, which is why it's not documented. At some point soon (Gradle 0.10,
maybe) we will tidy this up, and make it a public format. I'd also like
to add a plugin plugin, which would take care of generating any
meta-info files that need to get packaged up in the plugin jar (so that
you don't need to care about the formats or names of the meta-info files).
and then add a buildScript dependency on that jar. I presume the
auto-discovery will still work in this case but I haven't looked.
It does.
4) put the plug-in jar in some specific gradle place where it
auto-adds it (don't know the location off the top of my head and a
quick glance didn't find it). A build.gradle would only need the
apply call to use the plug-in.
This one we don't have (yet). You could add the jar to
$GRADLE_HOME/lib/plugins, but this isn't really recommended.
One option is for Gradle to provide a location in buildSrc (eg
buildSrc/plugins) where Gradle will look for plugin jars, and maybe
scripts too, to auto-add to the project.
Is there another one I'm missing?
Yes.
You can put the source for the plugin under buildSrc/src/main, and
Gradle will compile it and auto-include it in the project classpath. It
doesn't automatically apply the plugin, though. You need to do an apply
id: or apply type: in the build file.
First, I LOVE the apply url:'' stuff. I've already start simplifying
my local builds with this by ejecting my "setclasspath.cmd', etc.
tasks into local plug-ins. This feature is awesome.
In the vein of give me an inch and I'll take a mile, I'm wondering if
it would be a good idea to have an option that somehow combines the
buildScript dependency with the apply as separate in option (3) above.
Something like:
apply module:'groupId:artifact:version'
...with a default plug-in loaded or even spec'ed on the apply.
It combines the convenience of deployment style (1) with the
versioning and caching of (3).
Just a thought.
It's a good thought.
I like to separate how the plugin is packaged (ie in a script, or
classes in a jar, or as source in a directory, or scripts in jar) from
where the plugin is packaged (ie at a URL, in a repository, somewhere in
buildSrc) so that you can mix and match. That is, you should be able to
apply a plugin from a repository, whether it is packaged in a jar or as
a script. You should be able to apply a plugin from a URL, whether it is
packaged in a jar or as a script. And so on, for plugins in buildSrc, etc.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
