Finally, the build-automation tool is production-ready

Gradle goes 1.0!

Chris Mayer

At long last, the team behind Gradle have decided that their robust, enterprise-class build tool is definitely, definitely for production environments.

It’s been a long time coming. Ten milestones and two release candidates have passed, but Gradle 1.0 is finally production ready.

The announcement came last night from co-founder Adam Murdoch on the Gradle forums, with a short and sweet post, starting with the following:

While you’ve been waiting, we’ve been working. Many of you have been using Gradle in production for some time, and you’ve worked with us as we’ve built it into the robust, enterprise-class build tool it is today. Others have been waiting for this moment. And we’ve got some very good news for you.

Gradle is going 1.0.

For those somehow not aware of Gradle’s beauty, it’s builds upon what Apache Maven and Apache Ant does well, but injects a Groovy DSL to shake up the order of things.

It’s a big leap for the automation tool, further redefining how to build your project. A lot has changed for Gradle over the past year or so, as the release notes for Gradle 1.0 well detail. Gradle no longer relies upon the agile dependency manager, Apache Ivy (or its cache), opting for a rebuilt dependency resolution engine that claims to be ‘faster, more accurate and more flexible’. It’s a impressive rejigging – with an offline build mode fully enabled, complete DSL support for Maven and Ivy repository formats, the ability to refresh dependencies and better control over version conflict resolution, you just wonder how else Gradle can reinvent itself.

It has though. Elsewhere, the Gradle build daemon is a different beast, leaving its experimental phase primed for production with faster startup and execution times. New features should emerge as the project moves forward too. This release effectively signals that Gradle is lightning-quick. The aforementioned build times and dependency resolution are just the cherry on top – Java and Groovy compilation is faster too.

There’s support for the following, out-of-the-box, to check for Java code quality:

  • Sonar
  • FindBugs
  • PMD
  • Checkstyle
  • CodeNarc

IDEs have been quick to spot the potential of putting Gradle as part of their environment – with Eclipse STS, IntelliJ IDEA or NetBeans (experimental) all offering native integration. Away from that, there’s a new embedded Tooling API, meaning no one misses out.

It’s a fantastic effort from the Gradle team and wider community, who make it such an exciting open source project to monitor. What’s even better is that Gradle is set to evolve even further, if the very-thorough roadmap is to be believed.

Murdoch reveals the next stage for Gradle too:

We are continuing to improve Gradle across the board, but in the coming months we will focus on a few exciting features in particular…

We’d appreciate your feedback: if you have an opinion on any item in roadmap you can click through to the related forum entry and leave us a comment.

Post 1.0 is a time of planning for us, and we are now in the process of reworking our roadmap for the coming releases. So check the roadmap again in a week or two to get the most up-to-date picture of where we are heading.

Although many were utilising Gradle already in production, now Gradle’s gone 1.0 more will follow suit. If you were somehow tenative of using it to build, now is the time to amend that decision! Download here.

Inline Feedbacks
View all comments