On 10/01/2012, at 8:46 PM, Luke Daley wrote:

> Hi all,
> 
> As part of the recent build work, I added some services to gradle.org that 
> expose version information:
> 
> http://gradle.org/versions/nightly
> http://gradle.org/versions/release-candidate (returns 404 because there is no 
> active RC)
> http://gradle.org/versions/current
> 
> I added some tasks to our build to use these to update our wrapper:
> 
> https://github.com/gradle/gradle/blob/master/build.gradle#L451
> 
> We could potentially ship tasks that do this.
> 

I really like this idea.

We might add a wrapper plugin, that packages up a bunch of 
tasks/configuration/conventions for the wrapper. Combine this with a way to 
implicitly apply plugins from the command-line, this will give us (the start 
of) a nice command-line interface for managing a build. 

At some point, we also want to be able to get at this meta-data from the 
tooling API, so that we can expose the set of available versions, their 
statuses, etc. We might also expose the dynamic versions, too, via 
GradleConnector.useGradleVersion().

The wrapper task, wrapper executable, and above tooling API stuff all need to 
work from behind a firewall. As will whatever we do as far as downloading core 
(and custom) plugins goes, too. So far, we use 3 different domains for this 
stuff:
* downloads.gradle.org for the distributions.
* gradle.org for the meta-data.
* repo.gradle.org for jars (ie plugins).

To be corporate-firewall-friendly, we really should be hitting a single domain 
for everything that Gradle itself will download. A couple of options:
* Move the meta-data and the jars to downloads.gradle.org
* Move the meta-data and downloads to repo.gradle.org.

Also, we might consider structuring this stuff as a maven or ivy repository, so 
that it is easy to replicate in a corporate environment inside the firewall:
* Treat the distributions as artifacts.
* Turn the meta-data into a dumb artifact, rather than a smart service.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply via email to