Building and Testing with Gradle

Chapter 4. Maven and Gradle

Up to this point, you’ve seen the very light footprint of Gradle. You might be convinced it is the way to go for new projects. However, only a very few of us are blessed with the wide-open choices afforded to a greenfield project. The majority of us have an existing build system in place and the mandate to maintain continuity of the build. We might even have downstream clients of our JAR, WAR, and EAR binary artifacts. Gradle would only be a logical successor to Maven if it offered a very thoughtful path to both migration and integration from the world’s largest open source build system. It certainly does. Let’s take a look.

Cue Graven?

First, let’s provide a bearing on the attitude of Gradle. It is not the next incremental step after Maven. It is not just another Domain Specific Language (DSL) on top of the existing build tooling with which we are already familiar. It is, in fact, a progression of selected ideas of our existing build tools. Gradle brings only the best ideas forward and leaves behind the ones that fell short of their intended mark. That is a generic set of claims. Let’s proceed to specifics.

Caution

It would be easy to think of Polyglot Maven as an equivalent to Gradle, but alas, the constraints that apply to Maven apply to Polyglot Maven as well, just sans the angle brackets of XML. Gradle aims to be something more powerful than its predecessor tools in the build space.

Gradle takes the convention over configuration and consistently named ...