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

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

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

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

comments powered by Disqus