Gradle,Gradle,Gradle, With Gradle I Will Play!

I’ve recently spent some time writing an internal tool for my job, in the process of doing that I needed to get my head around Gradle. No easy task.

Gradle is a Groovy DSL, which means it’s like a hybrid between java and a functional language, with the benefits of having a domain specific language. The result is a super nice to use programming language that is used to build our code. In the case of the devenv, we use it to extract all the tools a developer or builder needs to build our product. Because the underlying implementation is just Groovy (which can be considered a clutter-free version of java), you have a great balance between writing targets ( or ‘tasks’ in Gradle nomenclature) which are simple and eloquent, and writing some flexible groovy methods.

Why is this good? Well, ant offers flexibility above all else, which leads to unwieldy, large XML documents, maven tries to bring order to the ant chaos by providing some metadata, and dependency management. That results in even bigger pom files which describe the project. Gradle takes the best of both; Ant’s flexibility, Maven’s metadata and dependency management, and adds lots of ‘sane’ defaults which can reduce the size of a build script file from 10000 lines to 100-200. This drastically increases the maintainability of a project.

Dependency Management. Less downloading the Internet! Our existing bootstrap process was a complicated piece of software written to achieve one task, download and unzip some files. Since its inception, many dependency management alternatives have cropped up in the wild; ivy, maven, gant, and now Gradle. The benefits of going with a solution we haven’t rolled ourselves are staggeringly high: new hires have a chance ( although slim) to have seen the technology before, experienced users can leverage knowledge from other areas such as android development, where Gradle grew it’s wings. Most importantly, there are really good docs online which cover the ins and outs of Gradle, there are tutorials, deep dive videos and sample code available for consumption.

Network Caching. Cache the World.  An initial bootstrap (from a developer/builder with no devenv) will take the same amount of time as a legacy bootstrap. All following bootstraps will take unchanged files from the built-in cache. This means that even if you blow away an entire stream (or have two streams) the latter stream will not be bound by network traffic, it will be bound by hard disk copy speeds. It will take about 1 minute rather than the 30 minutes it normally takes.

Integrates with everything. Out of the box, Gradle integrates with Jenkins. It integrates with Eclipse. It works on Windows, Linux, Builders, Artifactory. It has knowledge of what a JUnit is. It knows what a Java project should look like. It knows that if nothing has changed in a java source file, it doesn’t need to recompile. It works. Out of the box.


This sounds like you’re just listing off Gradle features. I am! Less magic, more simples! That’s exactly what’s happening here, we’re leaning on the power of an externally developed, globally used product. It’s open source, and although that’s a bit scary, it’s a trusted source, with a great community of developers behind it. Since Gradle 2.2 (we’re on 2.4 now) the compile speed has improved 1000%. Those two minor versions have been released in five months. We can expect some interesting updates in the next half of the year.

We were faced with a decision: extend the legacy bootstrap to work on Linux, or rewrite in Gradle. Rewriting our bootstrapping process in Gradle was the natural choice. Multiplatform comes nearly for free. We get the benefits of caching and UP-TO-DATE checks. The bootstrapping process is about to be rolled out across our products, and it will enable us to move to a Linux build farm, enable faster builds on both builders, and (more importantly?) developer workstations, and reduce the version drift on the wide array of projects and sub-projects which previously each had a separate inventory of devenv external versions.
By no means was it an easy task, but the juice was worth the squeeze.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s