On 27/02/10 8:28 PM, Gregory Boissinot wrote:
I'm afraid your proposals doesn't seem to work.
Where do you put the classpath element?
In the common script. You would take the entire body of the buildscript
{ } closure and move it into the common script, leaving behind
buildscript { apply url: 'common.gradle' }
In Fact, my operational use case are:
For each target script:
1. Retrieving a plugin
2. Declaring the plugin
3. Configuring it
buildscript {
repositores{
new org.apache.ivy.plugins.resolver.URLResolver()) {
name="Artifactory"
url= repositoryURL
addArtifactPattern "$url/[organisation]/[artifact]-[revision].[ext]"
addIvyPattern "$url/[organisation]/[artifact]-ivy-[revision].xml"
}
dependencies{
classpath "com.myorganisation:myplugin:1.0"
}
}
apply id: 'mypluginid'
configure(myConventionObject){
...
}
I've got lots of scripts that follows the same behavior with the same
plugin.
In my opinion, regarding this case, externalize the buildscript section in a
common buildscript makes sense.
It does. The question is how best to do this.
One option is to scan the build script for plugins that will be applied,
and extract the build classpath out of them before compiling the script.
This would have to be done recursively.
I think this would be tough to implement in a reliable way.
Another option is to move the boilerplate out of the buildscript { }
closure, so it can then more easily live in a common script. Something like:
repositories {
...
}
dependencies {
plugins 'myorg:myplugin:1.0' // plugins is a standard
configuration which defines the plugins classpath
}
apply id: 'mypluginid'
Another option is to reduce the boilerplate, so you don't need the
common script. Something like:
repositories {
...
}
apply group: 'myorg', name: 'myplugin, version: '1.0', id: 'mypluginid
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
