First and last, they hope

Gradle 1.0 release candidate surfaces

Chris Mayer

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!

Inline Feedbacks
View all comments