12 New Things I Learned From a Three Day Gradle Training

During the last three days, Sky was able to engage Luke Daley from Gradleware to come teach us about Gradle.

There was a lot of material covered. But the class format, short slides combined with 25 digestable exercises, made it fairly enjoyable. I would highly recommend this training to any team looking to elevate their understanding of Gradle. You can see a list of upcoming training courses on their website.

In this blog post, I will highlight 12 new things I learned from this training.

1. There are 3 phases to a build – init, configuration and execution

One of the key takeaways from this training is that there are three phases to a Gradle build.

The Init phase is just used to set up the Gradle build and add hooks, custom repos and other plugins. It’s not really as important as the next 2 phases.

The Configuration phase, on the other hand, is the one where most users of Gradle will interact with. The powerful task API allows you to sketch out all the steps of your build and Gradle thrives to make this phase fast and declarative.

This was very eye-opening for me. In the training, we focused on how to make sure that we only did configuration in this phase and separate it from task execution.

Luke gave an example of the Google Android plugin for Gradle, and emphasized how if you look at the task descriptions, you could see in the build.gradle file exactly WHAT your build was doing, without focusing on HOW it was doing it. Even though it had really complex functionality built in, these details were hidden away from the tasks into their execution phases.

Finally, in the Execution phase, you focus on HOW to actually perform the build and do build tasks. You can use a more programmatic API to move things into other build scripts and binary plugins to actually execute the build.

As someone who has dabbled in Gradle, having the two phases highlighted and explained made me really understand the philosophical differences between tools like Gradle and Maven / Ant. I would encourage anyone starting with Gradle to familiarize themselves with this separation.

2. Use the Daemon during development.

I was not aware that Gradle shipped with a daemon similar to Nailgun and GroovyServ. You enable it by adding org.gradle.daemon=true to your ~/.gradle/gradle.properties file. Enabling the daemon allowed a typically 8 second build to speed up to 2 seconds in my ancient macbook, win.

You can kill the Daemon by calling –no-daezmon, it also goes away after 3 hours of inactivity.

3. Defer execution in tasks by using groovy closures.

You often refer to tasks that have not yet been used in Gradle via their names in String. I.e, dependsOn ‘myTask’.

This strips out Gradle’s ability to validate that it exists and provide better error handling. You always want the actual task object over the string reference to it.

In the course, we learned that a technique to delay evaluation is to enclose things that are defined later in Groovy closures. So instead, use dependsOn { myTask }.

4. Prefer to write custom tasks over extending the Gradle DefaultTask.

Custom tasks provide many advantages over extending the Gradle DefaultTask. These includes dependency injection, inputs/outpus, validation and the ability to be moved into a plugin later on. Gradle does not intend to be comprehensive. Rather, it gives you a very powerful skeleton to flesh out the ultimate build system.

5. Fail Fast.

Gradle provides you with hooks to the taskGraph. You can use these hooks to validate that all the properties you need are present before the execution phase. This leads to better usability as users don’t have to sit through potentially long task executions only to be told a property is missing.

6. There are 4 log levels you need to care about.

Debug / info / lifecycle / quiet. Use -S to show the stack trace. If you use the lower case -s, it will filter out all the noise from Groovy.

7. Stack your plugins.

In the course, we learned that plugins like java in Gradle were actually split up into two plugins stacked on top of each other.

The first type is a capability based plugin – a plugin that provides some sort of functionality such as building and compiling java projects ( java-base plugin ).

Then, you stack a second plugin on top that is a convention based plugin – the plugin only provides sensible defaults to the project but implements little or no execution logic ( java plugin ).

The reason for this is that often you will have a build where conventions that ship with Gradle don’t really apply. It is easier to simply reference a base plugin and provide your own convention. This ties back to the configuration and execution phases.

Finally, there is a third type, a corporate plugin. These plugins allow you to lock down and enforce certain policies or conventions unique to your company. Luke points to a webinar available for more details on corporate plugins.

8. Lazy File Collections are pretty amazing.

In the training, we were introduced to Gradle fileTrees and fileCollections. These were dynamic, lazily executed structures that have a built-in live-filtering mechanism. You can apply filters and matchers to them, and as you add or remove content to them, the filters change.

This was one of the features that made my jaw hit the floor once I understood how they worked. Very powerful stuff that encourages more study.

9. Gradle is extremely extensible.

We learned about the ability to add methods, properties, objects and domain object containers to tasks. Central to Gradle’s philosophy is to allow you to easily name things that are associated with a build and create your own domain model for it. For example, Google created their own product flavours mechanism on top of Gradle. This idea is not available to naked Gradle, but since the Gradle API is so extensible, anyone can choose to extend it and adopt it to their needs.

10. Gradle plays nice with others.

We learned how Gradle easily integrates with Maven, Ivy, Ant and other build infrastructures. Some cool tidbits were shared around how you could use Ivy’s flexible repository mapping to map to Google’s hosted Javascript Libraries or James Ward’s WebJars project.

We learned a lot about dependency management. Gradle has this idea of configurations, which takes dependencies as an input and outpus artifacts. In fact, the entire task API revolves around taking inputs and connecting those into other outputs, making it very easy to understand and plug into other systems like ant and maven.

11. Gradle scripts can run in parallel. 

If you have a multi-project build, you can run projects in parallel with the –parallel flag. You can also define how many concurrent instances you want to run in parallel with –-parallel-threads=4.

Moreover, if you have a very large build and want to speed up it’s execution, you can use the –configure-on-demand flag to tell the build not to do it’s build organization logic ( which might take a while ) upfront and instead do this on the fly.

Tests can also be ran in multiple JVMs concurrently by setting the maxParallelForks property.

One day, I will buy a machine that is not powered by hamsters and Gradle will take advantage of all its cores.

12. Remember, it’s still Groovy.

Finally, we were reminded that despite it’s powerful API, Gradle is still a Groovy compatible project. We should try to keep most of our execution logic separate of the Gradle API and build our functionality using the same techniques we use for non-Gradle projects. It was very nice to be reminded of this because it demystifies Gradle development — you already know how to code for Gradle if you are a Groovy/Java developer.


This is just a short non-exhaustive list of things covered by the Gradle training.

The goal of the training was to get us ‘dangerous’ with Gradle — giving us enough knowledge to start exploring and writing code with Gradle beyond the typical ‘Copy and Paste from StackOverflow’ way of configuring build.gradle.

I would say the course was very successful in this goal and I look forward to using more Gradle in my day-to-day development. Thanks Gradleware!

14 thoughts on “12 New Things I Learned From a Three Day Gradle Training

  1. Pingback: Questa settimana in Grails (2013-17) - luca-canducci.com - Il blog di Luca Canducci: notizie, tips e nuove tecnologie dal mondo dell’IT.

  2. Pingback: An Army of Solipsists » Blog Archive » This Week in Grails (2013-17)

  3. Pingback: September Pocket link collection with 21 links

  4. AndyJ

    I don’t follow #4, Prefer to write custom tasks over extending the Gradle DefaultTask. I thought extending DefautTask WAS a custom task (per docs “To implement a custom task class, you extend DefaultTask.”). . . Can you help out?

    Nice write up, by the way. I wish I could get Gradle training. . .!

  5. Pingback: Gradle release ramblings | anorakgirl's blog

  6. Pingback: Gradle Training Review: 12 New Things from 3 Day Training!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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