On 24/02/10 10:33 AM, Paul Speed wrote:
Adam Murdoch wrote:
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.
Any thoughts on how this would work?
I'm just trying to think of a way to easily publish something like my
website plug-in (that may itself contain resources and other
dependencies) in a way that is as simple as the apply url:'' form but
that is versioned and cached like any other build script dependency.
One option, if everything is in a script, is to check the script into a
vcs which provides http access, something like github, for example. This
will provide you with the versioning part, as there's generally a way to
point at a particular revision or tag or branch using a url. We'd need
to add caching to Gradle for downloaded scripts for the caching part.
But we need to do this anyway.
Along similar lines, we might add a way to access vcs contents directly
via url, eg have Gradle understand svn: or git: urls.
Another option, if you don't want to use a script for some reason, is
that the plugin plugin would take care of most of the work of compiling,
assembling and uploading the jar to some repository. This might default
to a central Gradle plugin repository somewhere.
To upload the plugin, you'd just do 'gradle uploadArchives' and the
plugin plugin would take care of the rest.
To apply the plugin, you would do something like the following in your
build script:
repositories {
gradlePlugins() // use the central Gradle plugin repository.
}
apply module: 'myGroup:myPlugin:1.2'
Another option, is to add some kind of 'build from source' dependency to
Gradle, where Gradle fetches the source for the dependency, builds it,
and then adds the result to the classpath. This is very, very similar to
what Gradle does for the buildSrc project, and its really just a
generalisation of that that we can use elsewhere.
One such place would be for plugins. You would 'publish' a plugin by
just placing the source in some shared location and have Gradle take
care of building it when it needs to use it. For example, you could
point Gradle at a directory containing the plugin source. Or you could
point Gradle at some vcs url, and Gradle would download, build and
include it.
The concept of 'build from source' dependencies would be really useful
in other places. For example, you could have a set of loosely-coupled
builds, where Gradle will build a given project if it is present
locally, or download its artifacts from a repository if not.
It will be interesting to see how this develops.
I think this is the plan. We will see what emerges from how people use
this stuff, and make common things easier to do.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
