First and last, they hope

Gradle 1.0 release candidate surfaces

Chris Mayer
gradle

After highlighting their plans for Gradle, the team release what they hope will be the only candidate for the build automation tool

Tearing down the home straight towards their first major
version, the team behind the revolutionary build-automation tool,
Gradle have released a release
candidate for Gradle 1.0.

Core developer, Luke Daley hopes that this will be the
first (and hopefully last) release candidate’ for Gradle
1.0, unless some serious flaws are detected by users. The release
notes detail just some of the newest changes to the tool, most
notably with the Tooling API itself and we fully expect this
version to be dispatched as Gradle 1.0.

It is now possible to specify build arguments
(such as –no-search-upward, –project-dir, –info, –debug),
meaning greater usability for the Tooling API when driving builds
and also making it miles more convenient when writing custom builds
for Gradle plugins. The release notes state:

Specifically, you can use the Tooling API to
drive test builds that use your plugins. Previously, in order to
integ-test your custom Gradle plugins you had to either call
GradleMain directly or use deprecated GradleLauncher API. Neither
of those options was convenient because of the hassle with setting
up the classpath right. We will provide more information about new
ways for writing integration tests for your Gradle plugins
soon.

This feature is expected to make its way across to
the STS Eclipse Gradle plugin and IntelliJ IDEA
plugin.

There’s also new Groovy compiler integration
in the form of improved artifact detection. The new method means
Gradle can configure
a TTL for changing dependencies
. When that TTL
expires, Gradle will check to see if the resource has changed and
needs to be downloaded again.

Gradle will now first
compare 
ETag
header
 values, if the ETag has changed since last
time the resource was downloaded it is considered to be changed. If
the server does not send ETags, Gradle will fallback to comparing
the Last Modified and Content Length
values.

If either of these values have
changed since the last time Gradle downloaded the resource at that
URL, the resource is considered changed and will be downloaded. If
the server does not offer Last Modified and Content Length headers,
Gradle will then check for a sha1 checksum published alongside the
resource and compare it with the checksum of the cached
file.

For all details about the release candidate, check out the

Release Notes
for RC1 as well as the handy
Migration Guide
. You should also look at this post
by co-founder Adam Murdoch
regarding the future for Gradle,
showing a change in version numbering henceforth.

We hope that with this final version, more enterprises will pick
up the invaluable as a solution to their building woes. Keep your
eyes peeled for details post 1.0 – we’re certain that there will be
some great new features. Onwards to the next version!

Author
Comments
comments powered by Disqus