On 10 Jan 2012, at 22:22, Adam Murdoch wrote:
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/currentI added some tasks to our build to
use these to update our
wrapper:https://github.com/gradle/gradle/blob/master/build.gradle#L451We
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.
We are currently talking to contegix about options before we can
progress this. For the meantime we've reverted all the download urls
back to repo.gradle.org
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
