When we develop software, we write code, compile code, test our code, package our code, and finally, distribute the code. We can automate these steps by using a build system. The big advantage is that we have a repeatable sequence of steps. Each time, the build system will follow the steps we have defined, so we can concentrate on writing the actual code and not worry about the other steps.
Gradle is such a build system. In this chapter, we will explain what Gradle is and how to use it in our development projects.
Gradle is a tool for build automation. With Gradle, we can automate the compiling, testing, packaging, and deployment of our software or other types of projects. Gradle is flexible but has sensible defaults for most projects. This means we can rely on the defaults, if we don't want something special, but can still use the flexibility to adapt a build to certain custom needs.
Gradle is already used by big open source projects, such as Spring, Hibernate, and Grails. Enterprise companies such as LinkedIn also use Gradle.
Let's take a look at some of Gradle's features.
Gradle uses a Domain Specific Language (DSL) based on Groovy to declare builds. The DSL provides a flexible language that can be extended by us. Because the DSL is based on Groovy, we can write Groovy code to describe a build and use the power and expressiveness of the Groovy language. Groovy is a language for the Java Virtual Machine (JVM), such as Java and Scala. Groovy makes it easy to work with collections, has closures, and has a lot of useful features. The syntax is closely related to the Java syntax. In fact, we could write a Groovy class file with Java syntax and it would compile. But, using the Groovy syntax makes it easier to express the code intent, and we need less boilerplate code than with Java. To get the most out of Gradle, it is best to learn the basics of the Groovy language, but it is not necessary to start writing Gradle scripts.
Gradle is designed to be a build language and not a rigid framework. The Gradle core itself is written in Java and Groovy. To extend Gradle we can use Java and Groovy to write our custom code. We can even write our custom code in Scala if we want to.
Gradle provides support for Java, Groovy, Scala, Web, and OSGi projects, out of the box. These projects have sensible convention over configuration settings that we probably already use ourselves. But we have the flexibility to change these configuration settings, if needed, in our projects.
Gradle supports Ant tasks and projects. We can import an Ant build and re-use all the tasks. But we can also write Gradle tasks dependent on Ant tasks. The integration also applies to properties, paths, and so on.
Maven and Ivy repositories are supported to publish or fetch dependencies. So, we can continue to use any repository infrastructure we already have.
With Gradle we have incremental builds. This means tasks in a build are only executed if necessary. For example, a task to compile source code will first check whether the sources since the last execution of the task have changed. If the sources have changed, the task is executed, but if the sources haven't changed, the execution of the task is skipped and the task is marked as being up to date.
Gradle supports this mechanism for a lot of the provided tasks. But we can also use this for tasks we write ourselves.
Gradle has great support for multi-project builds. A project can simply be dependent on other projects or be a dependency for other projects. We can define a graph of dependencies between projects, and Gradle can resolve those dependencies for us. We have the flexibility to define our project layout as we want.
Gradle has support for partial builds. This means Gradle will figure out if a project that our project depends on needs to be rebuilt or not. And if the project needs rebuilding, Gradle will do this before building our own project.
The Gradle wrapper allows us to execute Gradle builds, even though Gradle is not installed on a computer. This is a great way to distribute source code and provide the build system with it, so that the source code can be built.
Also, in an enterprise environment, we can have a zero administration way for client computers to build the software. We can use the wrapper to enforce a certain Gradle version to be used, so the whole team is using the same version.