Gradle Effective Implementation Guide: A must-read for Java developers, this book will bring you bang up to date in the techniques of build automation using Gradle. A fully hands-on approach makes learning natural and entertaining.

In the first chapter we have already written our first build script. Let's create a similar build script with a simple task. Gradle will look for a file with the name build.gradle, in the current directory. The file build.gradle contains the tasks that make up our project. In this example, we define a simple task that prints out a simple message to the console:

project.description = 'Simple project'

task simple << {
    println 'Running simple task for project ' + project.description
}

If we run the build we see the following output in the console:

$ gradle simple
:simple
Running simple task for project Simple project

BUILD SUCCESSFUL

Total time: 2.08 secs

A couple of interesting things happen with this small build script. Gradle reads the script file and creates a Project object. The build script configures the Project object, and finally the set of tasks to be executed is determined and executed.

So, it is important to note that Gradle creates a Project object...

A project has one or more tasks to execute some actions, so a task is made up of actions. These actions are executed when the task is executed. Gradle supports several ways to add actions to our tasks.

We can use the doFirst and doLast methods to add actions to our task, and we can use the left shift operator (<<) as a synonym for the doLast method. With the doLast method or the left shift operator (<<) we add actions at the end of the list of actions for the task. With the doFirst method we can add actions to the beginning of the list of actions. The following script shows how we can use the several methods:

task first {
    doFirst {
        println 'Running first'
    }
}

task second {
    doLast { Task task ->
        println "Running ${task.name}"
    }
}

task third << { taskObject ->
    println 'Running ' + taskObject.name
}

When we run the script, we get the following output:

$ gradle first second third
:first
Running first
:second
Running...

We must keep in mind that Gradle scripts use Groovy. This means we can use all the Groovy's good stuff in our scripts. We already saw in our sample script the use of the so-called Groovy GString. The GString is defined as a string with double quotes and can contain references to variables defined in a ${...} section. The variabled reference is resolved when we get the value of the GString.

But other great Groovy constructs can also be used in Gradle scripts. The following sample script shows some of these constructs:

task numbers << {
    (1..4).each { number ->
        def squared = number * number
        println "Square of ${number} = ${squared}"
    }
}

task list {
    doFirst {
        def list = ['Groovy', 'Gradle']
        println list.collect { it[0].toLowerCase() }.join('&')
    }
}

And when we run the script we get the following output:

$ gradle -q numbers list
:numbers
Square of 1 = 1
Square of 2 = 4
Square of 3 = 9
Square of 4 = 16
...

Until now, we have defined tasks independent of each other. But in our projects we need dependencies between tasks. For example, a task to package compiled class files is dependent on the task to compile the class files. The build system should then first run the compile task, and when the task is finished, the package task must be executed.

In Gradle, we can add task dependencies with the dependsOn method for a task. First, let's look at a simple task dependency:

task first << { task ->
    println "Run ${task.name}"
}

task second << { task ->
    println "Run ${task.name}"
}

// Define dependency of task second on task first
second.dependsOn 'first'

Note that we define the dependency of task second on task first, in the last line. When we run the script, we see that the first task is executed before the second task:

$ gradle second
:first
Run first
:second
Run second

BUILD SUCCESSFUL

Total time: 2.145 secs

Another way to define the...

To execute a task we use the task name on the command line when we run Gradle. So, if our build script contains a task with the name first, we can run the task with the following command:

$ gradle first

But, we can also define a default task or multiple default tasks that need to be executed, even if we don't explicitly set the task name. So, if we run the gradle command without arguments, the default task of our build script will be executed.

To set the default task or tasks, we use the method defaultTasks. We pass the names of the tasks that need to be executed, to the method. In the following build script, we make the tasks first and second the default tasks:

defaultTasks 'first', 'second'

task first {
    doLast {
        println "I am first"
    }
}

task second {
    doFirst {
        println "I am second"
    }
}

We can run our build script and get the following output:

$ gradle
:first
I am first
:second
I am second

BUILD SUCCESSFUL

Total time: 2.097 secs

In Chapter 1, Starting with Gradle, we already learned that we could use the tasks task of Gradle to see which tasks are available for a build. Let us suppose we have the following simple build script:

defaultTasks 'second'

task first << {
    println "I am first"
}

task second(dependsOn: first) << {
    println "I am second"
}

Nothing fancy here. Task second is the default task and depends on task first. When we run the tasks task on the command line, we get the following output:

$ gradle -q tasks

---------------------------------------------------------
All tasks runnable from root project
---------------------------------------------------------

Default tasks: second

Help tasks
----------
dependencies - Displays the dependencies of root project 'chapter2'.
help - Displays a help message
projects - Displays the sub-projects of root project 'chapter2'.
properties - Displays the properties of root project 'chapter2'.
tasks - Displays the tasks runnable from...

Until now, we have added tasks to our build project using the task keyword followed by the name of the task. But there are more ways to add tasks to our project. We can use a string value with the task name to define a new task:

task 'simple' << { task ->
    println "Running ${task.name}"
}

We can also use variable expressions to define a new task. If doing so, we must use parentheses, because otherwise the expression cannot be resolved. The following sample script defines a variable simpleTask with the string value simple. This expression is used to define the task. The result is that our project now contains a task with the name simple:

def simpleTask = 'simple'

task(simpleTask) << { task ->
    println "Running ${task.name}"
}

We can run the tasks task to see our newly created task:

$ gradle -q tasks
...
Other tasks
-----------
simple
...

We can also use the power of Groovy to add new tasks. We can use Groovy's GString notation to dynamically...

Each task that we add is also available as a Project property, and we can reference this property like we can any other property in our build script. We can, for example, invoke methods or get and set property values of our task through the property reference. This means we are very flexible in how we create our tasks and add behaviour to the tasks. In the following script, we use the Project property reference to a task to change the description property:

task simple << { task ->
    println "Running ${task.name}"
}

// The simple task is available as project property.
simple.description = 'Print task name'
simple.doLast {
    println "Done"
}
project.simple.doFirst {
    println "Start"
}

When we run our task from the command line, we get the following output:

$ gradle -q simple
Start
Running simple
Done

A task object already has several properties and methods. But we can add any arbitrary new property to a task and use it. In the following sample, we print the value of the task property message. The value of the property is assigned with the statement simple.message = 'world':

task simple << {
    println "Hello ${message}"
}
simple.message = 'world'

When we run the task we get the following output:

$ gradle -q simple
Hello world

A common mistake when creating a task and adding actions for that task is that we forget the left shift operator (<<). Then we are left with a valid syntax in our build script, so we don't get an error when we execute the task. But instead of adding actions, we have configured our task. The closure we use is then interpreted as a configuration closure. All methods and properties in the closure are applied to the task. We can add actions for our tasks in the configuration closure, but we must use the doFirst and doLast methods. We cannot use the left shift operator (<<).

The following tasks do the same thing, but note the small subtle differences when we define the tasks:

def printTaskName = { task ->
    println "Running ${task.name}"
}

task 'one' {
    // Invoke doFirst method to add action.
    doFirst printTaskName
}

// assign action through left-shift operator (<<)
task 'two' << printTaskName

task 'three' {
    // This line will be...

Sometimes, we want tasks to be excluded from a build. In certain circumstances, we just want to skip a task and continue executing other tasks. We can use several methods to skip tasks in Gradle.

import static java.util.Calendar.*

task longrunning {
    onlyIf { task ->
        def now = Calendar.instance
        def weekDay = now[DAY_OF_WEEK]
        def weekDayInWeekend = weekDay in [SATURDAY, SUNDAY]
        return weekDayInWeekend
    }
    doLast {
        println "Do long running...

In this chapter we learned how to create tasks in a build project. We created tasks with actions in several ways and learned how to configure tasks.

We skipped tasks by using predicates, throwing StopExecutionException, and enabling or disabling a task. And we even learned how to skip tasks from the command line.

A very powerful feature of Gradle is the incremental build support. If a task is up-to-date, it isn't executed. We can define the rules for determining the up-to-date state in the tasks definition.

In the next chapter, we will take a more in-depth look at the Gradle Project object.