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.