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 build.gradle file 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:

// Assign value to description property. 
project.description = 'Simple project' 
 
// DSL to create a new task using 
// Groovy << operator. 
task simple << { 
    println 'Running simple task for project ' + 
      project.description 
} 

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

:simple
Running simple task for project Simple project
BUILD SUCCESSFUL
Total time: 0.57 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...

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. In this section, we discuss about the different ways to add actions to a task.

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}" 
    } 
} 
 
// Here we use the << operator 
// as synonym for the doLast method. 
task third << { taskObject...

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

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

task numbers << { 
    // To define a range of numbers 
    // we can use the following syntax: 
    // start..end. 
    // The each method executes the code 
    // in the closure for each element 
    // in a collection, like a range. 
    (1..4).each { number -> 
        // def is short for define. 
        // Used to define a variable without 
        // an explicit type of the variable. 
        def squared = number * number...

Until now, we have defined tasks independent of each other. However, 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 run the compile task first, 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. We can specify a task name as the String value or task object as the argument. We can even specify more than one task name or object to specify multiple task dependencies. 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 the second task on the first task, in the last line. When we run...

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 first name, we can run the task with the following command:

$ gradle first

However, 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 defaultTasks method. We pass the names of the tasks that need to be executed to the method. In the following build script, we make the first and second tasks 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...

In Chapter 1, Starting with Gradle, we already discussed that we could use the tasks task of Gradle to see the tasks that are available for a build. Let's 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. The second task is the default task and depends on the first task. 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
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 'organize'. [incubating]
dependencies...

Until now, we have added tasks to our build project using the task keyword, followed by the name of the task. However, 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, as follows:

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

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

// Define name of task 
// as a variable. 
def simpleTask = 'simple' 
 
// Variable is used for the task name. 
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...

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

// Create a simple task. 
task simple << { task -> 
    println "Running ${task.name}" 
} 
 
// The simple task is available as 
// project property. 
simple.description = 'Print task name' 
 
// We can invoke methods from the 
// Task object. 
simple.doLast { 
    println "Done" 
} 
 
// We can also reference the task 
// via the project property 
// explicitly. 
project.simple.doFirst { 
    println "Start" 
} 

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