Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Gradle: Hot or Not by Andres Almiray

Andres Almiray

Build tools are something developers have to interact with daily. More often than not, these interactions leave a sour feeling that the tool in question is just not really adequate (looking at you, Maven). Be it speed of your Gradle build, verbosity of Maven poms or the quantity of JavaScript build tools you need in a single project, you will leave the good parts unnoticed and concentrate on what annoys you. That’s why if you google any build tool, there’s so many more negative results. And sometimes it’s hard to get to know about the good bits of these tools.

However, this time Virtual JUG had the opportunity to invite and talk to one of the best Gradle experts in the world — Andres Almiray from Canoo. Andres is a Java Champion with more than 16 years of experience in software design and development, he’s a brilliant Java and Groovy developer, a true believer in the inevitable success of Gradle, and open source in general. He’s the spec lead of JSR 377 that tries to standardize common parts of standalone Java applications, both desktop and IoT ones.

Andres is a founding member of the Griffon framework and the Hackergarten community events. Andres has a blog and you can always find him on Twitter: @aalmiray

He talked about things that he finds the most attractive in Gradle and the best ways to organize a project, what to think of Gradle wrapper and how it helps you establish reproducible builds. This was a great live session with no slides, so Andres dove right into the topic and explained that the question now is not about whether you should consider using Gradle, but rather when should you switch your project to using Gradle for its build.

Without further ado, here’s the session for you viewing pleasure:

At the same time, let’s dive into what the session was about.

Andres really loves interactive sessions, so instead of showing us tons of slides, he decided to jump right in demoing good parts of Gradle.

The main thing that we picked up from the session, apart from the fact that Gradle is really amazing, is that there’s a variety of tools that surround Gradle itself and provide you with nice bits of functionality here and there.

This is a common approach in other areas, make small programs that do one thing and do it well, but until Gradle maybe build tools tried to do too much.

The first one that Andres showed us during the session is the Groovy enVironment Manager gvm. Inspired by similar tools in the Ruby ecosystem, gvm is a tool for managing multiple software versions on a single machine. Different projects need different Gradle versions? Not a problem, gvm will handle it. Want to throw in some Spring Boot action and try to build a nice microservice in under 100 minutes? Done! Gvm takes care of your environments, makes them isolated, updateable and prevents confusion.

When you’re done with the installation of Groovy itself, it’s time to kick off a project. While you might be interested in converting your most gigantic enterprise project to Gradle right away, it’s always smart to start with something smaller, perhaps a predefined template of a project to test things out.

Maven conveniently has a project templating functionality built in with the archetypes, Gradle reasonably doesn’t want to get into the mess of the project initialization. Don’t worry, there’s a command line tool that picks up the slack: lazybones.

You install lazybones from the gvm, and it is a project creation tool. In a nutshell, lazybones knows a number of project templates and will ask you some questions about the project metadata and in a matter of seconds you’ll have a fresh project setup.

All in all, after a quick lazybones create gradle-quickstart vjug, Andres showed us a new gradle project we explored for the rest of the session.

Now the organisation of a Gradle project and files is pretty straightforward and every project contains a build.gradle file, which declaratively states what the build commands for the project. You can apply various plugins to the build lifecycle or just write plain Groovy code there and confuse your teammates a bit.

Plugins that fit your project needs without any configuration can be just applied:

apply plugin: 'idea'
apply plugin: 'java'
apply plugin: 'jrebel'

There’s a section for specifying repositories where you want to check your dependencies from:

repositories { 
  jcenter()
}

JCenter is the Bintray’s Maven repository, which contains everything Maven Central has and other packages you won’t find anywhere else. Usually, specifying jcenter repository should be enough to access any open-sourced library.

Gradle clearly knows that building a project and consuming the same project as a dependency are two different things, so it separates the instructions for these two activities. File build.gradle contains all the data one needs to build the project, but when deploying the artifact to the Maven repository, Gradle will generate the pom.xml that contains just the runtime repositories. Which is really smart, if you ask me.

In fact, Gradle does many things in a smart way. For instance, Andres showed how Gradle caches the results of the previous build and if nothing has changed in the project it reuses the cache saving you the precious CPU cycles and some time every single time you build the project after introducing some local modifications.

Gradle goes further and checks the entire tree of your project modules for changes, if you have two modules and the dependency module is changed, then Gradle will figure it out and build that even if you ask to just build the dependent module.

There’s a rumor that you can achieve the same with Maven and a number of command line params, but if you watch the session, you’ll see what happens when we tried it.


Two other things Andres talked about are Gradle versions plugin, which helps you maintain the versions of your dependencies. It can figure out which dependencies have released an update and magically make you use the latest stable version if you want that.

Gradle wrapper screenshot

The other one is Gradle wrapper. In a nutshell, the wrapper is a tiny JVM process, that starts when you invoke the build, but doesn’t finish at the end of it. The next time you build the project, the wrapper is already loaded and warmed up, so the build will take a couple of seconds less. All in all it saves you some annoyance about the speed of the Gradle build.

According to the documentation, Gradle wrapper is the preferred way of starting a Gradle build.

These were perhaps the main things we picked up from the session, but there were many more little things that Andres showed and explained to us. It’s always a pleasure to watch someone who knows what they are doing, and a great way to introduce Gradle to yourself will be to go and watch this excellent Virtual JUG session.

Interview and final words

After the session, as usual we got a chance to interview Andres about what he really thinks about Gradle, what are other build tools that regularly exceed expectations, how can one get into the Hackergarten community.

The video of our quick chat is right below, watch it, ping Andres on Twitter: @aalmiray, and tell him or us (@ZeroTurnaround) what you think?

Are you using Gradle, would you pick it up for your next project?

If you leave your email in the form below, I’d be happy to send you an occasional email about what’s happening with RebelLabs, the best pieces of content we have and what’s happening in the world of Java in general.

 


Read next:

  • Frantisek

    Good article, but there is inaccuracy in the description of the gradle wrapper. You have mixed gradle wrapper with gradle daemon.