At the time of writing, Gradle is less commonly used in Java enterprise projects than Apache Maven. This may be due to enterprise developers often being unfamiliar with dynamic JVM languages such as Groovy, which Gradle uses as its build script language. However, writing Gradle build files doesn't require deep knowledge of Groovy.

Gradle comes with quite a few benefits, most importantly its flexibility. Developers can leverage the full power of a programming language in order to define and potentially customize the project build.

Gradle will keep a daemon running in the background, that is being reused after the first build, to speed up subsequent build executions. It also keeps track of build inputs and outputs, whether changes have been made since the last build execution. This enables the system to cache steps and decrease the development build time.

However, depending on the complexity of the project and its used dependencies this optimization might not even be required. Chapter 4, Lightweight Java EE will cover the impact of project dependencies and zero-dependency applications.

The following snippet shows the build structure of a Gradle project:

As you can see, the structure is quite similar to Maven projects, with the difference being that built binaries are per default placed into the build directory.

It's common for Gradle projects to include a wrapper script for environments that have no Gradle installations.

The following code demonstrates an example of a build.script file:

plugins {
    id 'war'
}

repositories {
    mavenCentral()
}

dependencies {
    providedCompile 'javax:javaee-api:8.0'
}

Gradle build tasks are triggered via the command line, using gradle or the provided wrapper scripts. Executing gradle build, for example, is the analog of mvn package, compiling the sources, executing tests and building the artifact.

There are certain benefits of having a fully-fledged programming language defining the build files. With the build scripts being treated as code, developers are encouraged to apply clean code principles for definitions that become too complex. Sophisticated build steps can, for example, be refactored into several, readable methods.

However, this power also brings the danger of over-engineering the build. As said, the inflexibility of Apache Maven can be considered a feature; the possibility of easily customizing build scripts eventually leads to build definitions that are very specific to the project. Compared to Maven, overly-customized builds can be an obstacle for developers who are unfamiliar with the project.

Experience shows that the vast majority of enterprise project builds are quite similar. This raises the question of whether the flexibility Gradle provides is required. Projects that don't have any special requirements, unlike for example product development, are sufficiently covered using Maven as build system.

The rest of this book will thus use Maven when a build system is required as an example. All code examples, however, are equally well suited to use Gradle.