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.
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) 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. This still requires the apply id: or
apply type: call.
[Actually, I've seen mentions of this .properties file but I haven't
traced through the things like src/META-INF/java.properties to see how
that actually gets resolved in the final build.]
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.
Is there another one I'm missing?
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.
-Paul
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
