We are embarking on a fast-paced ride to learn the Gradle Essentials. To take a gentle start, we will first install Gradle. Then, we will get friendly with the Gradle's command-line interface by looking at the usage of the gradle command. Also, by the end of this chapter, we would have run our first Gradle build script.
Building a software artifact is a complex process involving various activities such as compiling source code, running automated tests, packaging distributable files, and so on. These activities are further split into many steps, often dependent on the execution order, fetching dependent artifacts, resolving configuration variables, and so on. Executing all these activities manually is cumbersome and often error-prone. A good build automation tool helps us reduce the effort and time it takes to build correct artifacts in a repeatable manner.
Gradle is an advanced build automation tool that brings the best from various proven build tools and innovates on top of them. Gradle can be used to produce artifacts such as web applications, application libraries, documentation, static sites, mobile apps, command lines, and desktop applications. Gradle can be used to build projects based on various languages and technology stacks such as Java, C/C++, Android, Scala, Groovy, Play, Grails, and many more. As Java Virtual Machine (JVM) happens to be one of the first class supported platforms by Gradle, the examples in this book will mostly focus on building Java-based projects.
Gradle gives us full control over build just like Ant but without ever needing to repeat ourselves by providing intelligent defaults in the form of conventions. Gradle truly works by conventions over configuration, just like Maven. However, it never gets in our way when we need to deviate. Also this puts it in complete contrast with Maven. Gradle attempts to maintain the right balance between conventions and configurability.
The previous generation of build tools, such as Ant and Maven, chose XML to represent the build logic. While XML is human-readable, it is more of a machine-friendly format (easier to be read/written by programs). It is great for representing and exchanging hierarchical data, but when it comes to writing any logic, even the simplest logic can easily take hundreds of lines. On the other hand, a Gradle build can be configured using very human-friendly Groovy DSL. Groovy is a powerful, expressive, and low ceremony dynamic language and is a perfect fit for build scripts.
Gradle itself is a JVM application written in Java and Groovy. Since Gradle runs on the JVM, it runs the same way on Windows, Mac OS X and Linux. Gradle also boasts an advanced dependency resolution system and can resolve dependencies from the existing Maven and Ivy repositories or even a file system.
Over the years Gradle has matured into a very stable open source project with active contributors and commercial backing. The rich plugin ecosystem and vibrant community makes Gradle an excellent choice for a variety of projects. Gradle already has an impressive list of adopters, which includes tech giants such as Google Android, LinkedIn, Unity 3D, Netflix and many more. Open source libraries and frameworks such as Spring, Hibernate, and Grails are using Gradle to power their builds.
Before we move forward with running Gradle, we must have it installed on our machine. There are multiple ways through which Gradle can be installed and updated. We will first see a more manual way to install Gradle and then take a quick look at installing it via some commonly used package managers. We can choose any one method that fits the bill. Irrespective of the way we install Gradle, we must meet the following prerequisite.
Gradle needs Java Runtime Environment (JRE) 6 or Java Development Kit (JDK) 1.6 or higher. There is no other dependency. We recommend having JDK installed. To verify this, on the command line, we can check the Java version with the following command:
$ java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
If we don't see the output more or less like the one shown in the preceding command, there is problem with our JDK installation.
Note
The latest JDK can be downloaded from the following URL:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
If we want a finer control over the installation then this is a suitable route. This could be the case, when we cannot use the package managers, want very specific binaries to be downloaded and installed, or behind corporate firewalls where automatic downloading by package managers is not allowed. We need to download the Gradle binaries and make them available for use on the command line.
The latest Gradle distribution can be downloaded from http://www.gradle.org/downloads. As of writing the latest version is 2.9.
Gradle binary distribution comes in two flavors as follows:
gradle-2.9-all.zip: This contains binaries, sources, and documentationgradle-2.9-bin.zip: This contains binaries only
We can download any of the above depending on what we need. Also, this is an OS-independent zip so the same zip can be extracted on Mac OS X, Windows, and Linux. The next section makes the Gradle command available on the command line. This section is dependent on the OS we use.
Let's say we extracted the downloaded zip as ~/gradle-2.9/. Now, we just need to add the following two lines at the end of .bashrc/, .bash_profile/, or .zshrc, depending on the OS and the shell that we use:
export GRADLE_HOME=~/gradle-2.9 export PATH=$PATH:$GRADLE_HOME/bin
Restart the terminal or source the modified file to have the change take effect.
Let's say we extracted the zip as C:\gradle-2.9, then perform the following steps:
Open the Start menu, right click on Computer and select Properties.
On Advanced system settings, select the Advanced tab, and then select Environment Variables....
Create a
GRADLE_HOMEenvironment variable with the valueC:\gradle-2.9.Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Edit (or add if not already there) the
PATHenvironment variable. At the end of its value, append;%GRADLE_HOME%\bin(add a semicolon if multiple path entries exist).
Although the manual installation gives absolute control over the installation process, various tasks such as downloading and extracting the right version, upgrading to the latest versions, uninstalling, and editing environment variables quickly become cumbersome and error-prone. That is why many people prefer package managers to control the whole process.
While installing manually, as mentioned in the previous section, is very easy, we can make it super-easy by using a package manager.
Some Linux distributions like Ubuntu ship with their package manager, Mac OS X, Windows don't have any package manager installed by default. However, luckily, there are multiple package managers available for both platforms. We will see the example of Homebrew on Mac and Chocolatey on Windows.
Make sure we have Homebrew installed. If it is, installing Gradle is only a matter of using the following command:
$ brew install gradle
Note
More details on Homebrew can be found at http://brew.sh.
Using the built in package manager on Ubuntu, which is called Advanced Packaging Tool (APT), we can install Gradle with the following command:
$ sudo apt-get install gradle
If we have Chocolatey installed, installing Gradle is just a command away:
c:\> cinst gradle
Note
More details on Chocolatey can be found at https://chocolatey.org.
SDKMAN stands for the Software Development Kit Manager. In its own words, the website describes it as: SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems.
The advantage SDKMAN has over other package managers is that we can have multiple Gradle versions installed on a system and select a different version for a given project. If we have it installed, all we need to do is run following command:
$ sdk install gradle
SDKMAN can be installed from http://sdkman.io/.
In whichever way we choose to install Gradle, it's a good idea to verify that if it's working before we move ahead. We can do this by simply checking for Gradle's version on the command line:
$ gradle --version ------------------------------------------------------------ Gradle 2.9 ------------------------------------------------------------ Build time: 2015-11-17 07:02:17 UTC Build number: none Revision: b463d7980c40d44c4657dc80025275b84a29e31f Groovy: 2.4.4 Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013 JVM: 1.8.0_25 (Oracle Corporation 25.25-b02) OS: Mac OS X 10.10.5 x86_64
If we see output similar to the above, we have Gradle installed correctly on our machine.
Although it's not required most of the time, but if in case we need to set some global options for the JVM that Gradle will use, Gradle provides us a convenient way to do that. We can set the GRADLE_OPTS environment variable with acceptable flags to tune the JVM.
Gradle also honors the JAVA_OPTS environment variable. However, we need to be careful when setting it, as this affects the setting for all the Java programs on a machine. Setting that we want to keep common for all the Java apps should be done via this variable and those that only need to be applied to Gradle should be set via GRADLE_OPTS.
Gradle, just like other build tools, is primarily run from a command line. That's why it is worth spending some time to get familiar with its command-line interface. Typically, a gradle command is issued from the root of a project directory with some tasks to be executed. Let's say we are in the hello-gradle directory, which is currently empty.
Gradle provides a very simple command-line interface (CLI), which takes the following form:
gradle [options…] [tasks…]
As we can see, apart from the gradle command itself, everything else is optional. The options tweak the execution of the Gradle whereas tasks, which we will see in detail later, are the basic units of work. Options are common across all projects and are specific to Gradle but tasks may vary depending on the project in which the gradle command is being run.
There are some tasks that are available on all projects. One such task is help:
$ gradle help :help Welcome to Gradle 2.9. To run a build, run gradle <task> ... To see a list of available tasks, run gradle tasks To see a list of command-line options, run gradle --help To see more detail about a task, run gradle help --task <task> BUILD SUCCESSFUL Total time: 0.639 secs
Gradle is helping us out by telling us how to find all the available tasks and list all command-line options. Let's first check what other tasks are currently available on our project. Remember we are still in the empty directory hello-gradle:
$ gradle tasks :tasks ------------------------------------------------------------ All tasks runnable from root project ------------------------------------------------------------ Build Setup tasks ----------------- init - Initializes a new Gradle build. [incubating] wrapper - Generates Gradle wrapper files. [incubating] Help tasks ---------- components - Displays the components produced by root project 'hello-gradle'. [incubating] dependencies - Displays all dependencies declared in root project 'hello-gradle'. dependencyInsight - Displays the insight into a specific dependency in root project 'hello-gradle'. help - Displays a help message. model - Displays the configuration model of root project 'hello-gradle'. [incubating] projects - Displays the sub-projects of root project 'hello-gradle'. properties - Displays the properties of root project 'hello-gradle'. tasks - Displays the tasks runnable from root project 'hello-gradle'. To see all tasks and more detail, run gradle tasks --all To see more detail about a task, run gradle help --task <task> BUILD SUCCESSFUL Total time: 0.652 secs
This shows us some generic tasks that are available even without us adding any task to our project. We can try running all these tasks and see the output. We will see these tasks in details in the upcoming chapters.
The other useful command gradle help suggested us to check all the available options with the --help option.
When we run the gradle --help command, we get the following output:
$ gradle --help USAGE: gradle [option...] [task...] -?, -h, --help Shows this help message. -a, --no-rebuild Do not rebuild project dependencies. -b, --build-file Specifies the build file. …..
(The output is truncated for brevity.)
The option has a long form such as --help and may have a short from such as -h. We have already used one option before, that is --version or -v, which prints information about the Gradle version. The following are some commonly used options; there are many more options, which can be seen using the gradle --help command:
|
Options |
Description |
|---|---|
|
|
This specifies a build file (default: |
|
|
This continues task execution even after a task failure |
|
|
This sets the system property of the JVM |
|
|
This prints debug level logs |
|
|
This starts Gradle GUI |
|
|
This prints info level logs |
|
|
This adds a property to the project |
|
|
This logs only errors |
|
|
This prints stack traces for exceptions |
|
|
This excludes a specific task |
So we are now ready to get our feet wet and see our first Gradle script in action. Let's create a file called build.gradle in the hello-gradle directory. Unless the build file path is provided using the --build-file option, Gradle treats the current directory as a project root and tries to find the build.gradle file there. If we have used Ant or Maven earlier, we can relate this file with build.xml or pom.xml, respectively.
Now, open the build.gradle file and let's declare a task by adding the following line:
task helloWorld
We should be able to see this task on the command line as follows:
$ gradle tasks ... Other tasks ----------- helloWorld ...
Here, we have successfully created a task object called helloWorld. Tasks are first-class objects in Gradle, which means they have properties and methods on them. This gives us tremendous flexibility in terms of customizability and programmability of build.
However, this task actually does not do anything yet. So let's add some meaningful action to this task:
task helloWorld << {
println "Hello, World!"
}Now from the command line, we can execute this task by issuing the following command:
$ gradle -q helloWorld Hello, World!
Notice that we used the –q flag to reduce the verbosity in the output. When this task is run, we see the output that our task generates but nothing from Gradle unless it's an error.
Now, let's try to briefly understand the build.gradle file. The first line declares the tasks and starts the body of a code block that will be executed at the end. The left shift operator (<<) might feel oddly placed, but it is very important in this context. We will see in the later chapters what it exactly means. The second line is a Groovy statement that prints the given string to the console. Also, the third line ends the code block.
While calling a gradle task from a command line, we can save a few keystrokes by typing only the characters that are enough to uniquely identify the task name. For example, the task helloWorld can be called using gradle hW. We can also use helloW, hWorld, or even heWo. However, if we just call gradle h, then the help task will be called.
This comes very handy when we need to frequently call long Gradle task names. For example, a task named deployToProductionServer can be invoked just by calling gradle dTPS, provided that this does not match any other task name abbreviation.
While we are talking about frequently calling Gradle, it is a good time to know about a recommended technique to boost the performance of our builds. Gradle Daemon, a process that keeps running in the background, can speed up the builds significantly.
For a given gradle command invocation, we can specify the --daemon flag to enable the Daemon process. However, we should keep in mind that when we start the daemon, only the subsequent builds will be faster, but not the current one. For example:
$ gradle helloWorld --daemon Starting a new Gradle Daemon for this build (subsequent builds will be faster). :helloWorld Hello, World! BUILD SUCCESSFUL Total time: 2.899 secs $ gradle helloWorld :helloWorld Hello, World! BUILD SUCCESSFUL Total time: 0.6 secs
In the preceding example, if we notice the time taken by two runs, the second one completed much faster, thanks to the Gradle Daemon.
We can also prevent a specific build invocation from utilizing a Daemon process by passing the --no-daemon flag.
There are various ways to enable or disable Gradle Daemon, which are documented at https://docs.gradle.org/current/userguide/gradle_daemon.html
A Gradle Wrapper consists of a gradlew shell script for Linux/Mac OS X, a gradlew.bat batch script for Windows, and a few helper files. These files can be generated by running a gradle wrapper task and should be checked into the version control system (VCS) along with project sources. Instead of using the system-wide gradle command, we can run the builds via the wrapper script.
Some of the advantages of running builds via a wrapper script are as follows:
We don’t need to download and install Gradle manually. The wrapper script takes care of this.
It uses a specific version of Gradle that the project needs. This reduces the risk of breaking a project’s build because of incompatible Gradle versions. We can safely upgrade (or downgrade) the system-wide Gradle installation without affecting our projects.
It transparently enforces the same Gradle version for our project across all developers’ machines in the team.
This is extremely useful in Continuous Integration build environments, as we do not need to install/update Gradle on the servers.
The Gradle wrapper task is already available to all Gradle projects. To generate the wrapper scripts and supporting files, just execute the following code from the command line:
$ gradle wrapper
While generating wrapper, we can specify the exact Gradle version as follows:
$ gradle wrapper --gradle-version 2.9
In this example, we are specifying the Gradle version to be used is 2.9. After running this command, we should check-in the generated files into VCS. We can customize the wrapper task to use a configured Gradle version, produce wrapper scripts with different names, change their locations, and so on.
For availing the benefits of a wrapper script, instead of using the gradle command, we need to call the wrapper script based on our OS.
On Mac OS X/Linux:
$ ./gradlew taskName
On Windows:
$ gradlew taskName
We can use the arguments and flags exactly in the same way as we pass to the gradle command.
In this chapter, we started with a brief introduction to Gradle. Then, we looked at manual installation and also installation via package managers. We also learned about Gradle's command-line interface. Also, finally, we wrote our first Gradle build script.
If you have followed the chapter until this point, you are all set to check out any Gradle-based project on your machine and execute builds. Also, you are equipped with the knowledge to write a very basic Gradle build script. Going forward, we will look at building Java-based projects with Gradle.
