On 17/07/2011, at 7:56 AM, cquinn wrote:
> Yes, exactly. I have a single line buildscript entry now for grabbing the
> plugin jar from the SCM workspace while I am working out the details of
> bootstrapping. Like this:
>
> buildscript { dependencies { classpath fileTree(dir:
> '../../../Tools/nebula/build/libs', include: '*.jar') }}
>
> But it could get more sophisticated, so I would like to make it centralized
> and reusable. I can see wanting to have it setup the classpath automatically
> to get all of our build plugins from a number of possible places, and for
> different levels of stabilities. Once the users' build.gradle scripts have
> the right buildscript classpath, everything else can be done in the plugins.
I wonder if we might take advantage of the wrapper here, to provide some
conventional place to find and execute this bootstrapping logic.
For example, perhaps the wrapper looks for a
${distributionDownloadLocation}/init.gradle when it downloads the distribution,
and if found, applies this init script when it invokes Gradle. We'd combine
this with improving the init script DSL.
To provide custom organisation-wide logic, you'd publish a Gradle distribution
and an init script to some location, and point your builds at this location.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
