Task Dependencies: Gradle

Steven J Zeil

Last modified: Feb 22, 2021
Contents:
1 Gradle Overview
1.1 What to keep and leave from Ant
1.2 What to keep and leave from Maven
1.3 What does Gradle offer?
1.4 The Gradle Wrapper
2 gradle by example
2.1 Simple Java Build
2.2 Java Build with Third-Party Libraries
2.3 Java Build with Unit Tests
2.4 C++ Multi-project Build
3 Customizing Tasks
3.1 Gradle Tasks
3.2 Anatomy of a Task
3.3 Task Dependencies
3.4 Tasks

Abstract

Gradle is a build manager based upon an Ant-like task dependency graph expressed in a more human-friendly notation, with a Maven-like ability to express standard project layouts and build conventions.

In this lesson we look at how Gradle combines some of the better features of Ant and Maven, while providing a more convenient notation than either.

We will look at how Gradle could be applied to some of our sample projects.

1 Gradle Overview

1.1 What to keep and leave from Ant

Keep:

Leave

“XML was an easy choice for a build tool a decade ago, when it was a new technology, developers were enthusiastic about it, and no one yet knew the pain of reading it in large quantities. It seemed to be human-readable, and it was very easy to write code to parse it. However, a decade of experience has shown that large and complex XML files are only easy for machines to read, not for humans. Also, XML’s strictly hierarchical structure limits the expressiveness of the format. It’s easy to show nesting relationships in XML, but it’s hard to express program flow and data access the way most common programming language idioms express them. Ultimately, XML is the wrong format for a build file.”

Tim Berglund, Learning and Testing with Gradle

1.2 What to keep and leave from Maven

Keep:

Leave

1.3 What does Gradle offer?

1.4 The Gradle Wrapper

Suppose that you are building your project with Gradle.

If you set up your project with the Gradle Wrapper, you get a simple script named gradlew.

This works nicely for projects that distribute their source code via any of the version control systems that we will be discussing later.

2 gradle by example

A gradle project is controlled by two build files

I’ll work through a progressive series of builds for this project.

2.1 Simple Java Build

Using the Java plugin, a basic build with unit tests is easy:

settings.gradle

// A simple Java project

This file needs to exist, but can be empty.

build.gradle

plugins {
   id 'java'  ➀
}

repositories { ➁
    jcenter()
}

This is all you need to compile Java code stores in src/main/java.

2.2 Java Build with Third-Party Libraries

plugins {
   id 'java'
}

java {
    sourceCompatibility = JavaVersion.toVersion(11)   ➀
    targetCompatibility = JavaVersion.toVersion(11)
}

repositories {                ➁
    jcenter()  
}

dependencies {                ➂
    implementation 'com.opencsv:opencsv:5.1'
    implementation 'commons-io:commons-io:2.6'
}

2.3 Java Build with Unit Tests

If you have unit tests, we need to add a little more info.

build.gradle

plugins {
   id 'java'
}

repositories {
    jcenter()
}

dependencies {
    implementation 'com.opencsv:opencsv:5.1'
    implementation 'commons-io:commons-io:2.6'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.7.0' ➀
}

test {  ➁
    ignoreFailures = true ➂
    useJUnitPlatform()
}

The two sections at the end establish that

2.4 C++ Multi-project Build

 

A multi-project build in gradle is kept in a directory tree.

2.4.1 The master project

Any multi-project build in Gradle uses the settings.gradle file (usually in the common root containing the subproject directories) to identify the subprojects:

rootProject.name = 'manhattan'

include "application", "geomlib"

In this case, we have two subprojects. One provides the executable, the other a library of ADTs, with unit tests, constituting the bulk of the code design.

There is no need for build.gradle file at this level, although it would be legal to provide one if you have project-level steps to be carried out.

2.4.2 The geomlib subproject

Of the two subprojects, the geomlib subproject is probably most interesting because it does the most. It compiles code into a library, then compiles and runs unit tests on that library code. By contrast, the application subproject only compiles code.

Here is the build.gradle file for the lib subproject:

build.gradle.lib.listing 
plugins {
    id 'cpp-library'
	id 'cpp-unit-test'
}


unitTest {
    binaries.whenElementKnown(CppTestExecutable) { binary ->
        if (binary.targetMachine.operatingSystemFamily.linux) {
            binary.linkTask.get().linkerArgs.add('-pthread')
        }
    }
}

2.4.3 The application subproject

The application subproject is simpler, because it only has one job to do – create an executable. This project depends on the geomlib subproject. The library must have been constructed before the code in the application subproject can be compiled.

Here it is:

build.gradle.exe.listing 
plugins {
		id 'cpp-application'
}

dependencies {
			implementation  project(':geomlib')
}

You can find this entire project, with the Gradle files, here.

3 Customizing Tasks

The gradle build files are Groovy scripts, with Java-like syntax. Many of the more common Java API packages are imported automatically.

task upper {
    doLast {
       String myName = "Steven Zeil";
       println myName;
       println myName.toUpperCase();
    }
}

If this is placed in build.gradle, then we can run it:

$ gradle upper
:upper
Steven Zeil
STEVEN ZEIL

BUILD SUCCESSFUL

Total time: 1.747 secs
$

3.1 Gradle Tasks

The basic elements of a Gradle build file are tasks.

3.2 Anatomy of a Task

3.2.1 The phases of a Gradle run

Before looking at the components of a task, we need to understand a bit about how Gradle works.

 

A Gradle run occurs in four specific phases.

  1. Initialization takes care of things that affect how Gradle itself will run. The most visible activity during this phase is loading Gradle plugins that add new behaviors.

  2. Configuration involves collecting the build’s tasks, setting the properties of those tasks, and then deciding which tasks need to be executed and the order in which that will be done.

  3. Execution is when the tasks that need to be executed get run.

  4. Finalization covers any needed cleanup before the Gradle run ends.

Software developers will be mainly concerned with the middle two phases. For example, if we need to compile some Java source code for a project, then we would want to configure that task by indicating the source code directory (or directories) and the destination for the generated code. With that information, Gradle can look to see if the .class files already exist from a prior run and whether the source code has been modified since then. Gradle can then decide whether or not the compilation task actually needs to be run this time. This decision is remembered during the execution phase when the task will or will not be run, accordingly.

3.2.2 Declaring tasks

A Gradle task can be declared as easily as:

task myTask
 

A Groovy function with parameters, e.g.,

void foo (int x, int y, int z) { ... }

can be called using positional arguments:

foo (12, 14, 0)

or by using named arguments:

foo (z: 0, x: 12, y: 14)

One advantage of the latter form is that you don’t have to know the order in which the parameters appeared in the function declaration. The named form is even more useful when all or most of the parameters have default values and, in your call, you only want to supply the value to one or two parameters for which you don’t like the defaults.

Some tasks may need parameters:

task copyResources (type: copy)

3.2.3 Configuring tasks

You can add code to be run at configuration time by putting it in { } brackets just after the task name:

task copyResources (type: Copy)

copyResources {
    description = 'Copy resources into a directory from which they will be added to the Jar'
    from(file('src/main/resources'))
    into(file('target/classes'))
}

You can combine a configuration with the task declaration:

task copyResources (type: Copy) {
    description = 'Copy resources into a directory from which they will be added to the Jar'
    from(file('src/main/resources'))
    into(file('target/classes'))
}

3.2.4 Executable Behavior

3.2.5 Adding Executable Behavior

3.3 Task Dependencies

 

task setupFormat

task setupGraphics

task setupSourceCode


task generatePDFs (dependsOn: 'setup')
generatePDFs.doLast {  ➀
    println 'in task generatePDFs'
}

task setup (dependsOn: ['setupFormat',
                        'setupGraphics',
                        'setupSourceCode'])
setup.doLast {  ➁
   println 'in task setup'
}

task deploy (dependsOn: generatePDFs)
deploy.doLast {
    println 'in task deploy'
}

Running this gives:

$ gradle deploy
:setupFormat UP-TO-DATE
:setupGraphics UP-TO-DATE
:setupSourceCode UP-TO-DATE
:setup
in task setup
:generatePDFs
in task generatePDFs
:deploy
in task deploy

3.3.1 Appending to Tasks

doLast (and doFirst) add actions to a task.

If we add the following to the previous script:

setup.doLast {
    println 'still in task setup'
}

$ gradle deploy
:setupFormat UP-TO-DATE
:setupGraphics UP-TO-DATE
:setupSourceCode UP-TO-DATE
:setup
in task setup
still in task setup
:generatePDFs
in task generatePDFs
:deploy
in task deploy

3.4 Tasks

At its heart, a build file is a collection of tasks and declarations.

3.4.1 Using Java within tasks

task playWithFiles {
    doLast {
        def files = file('src/main/data').listFiles().sort()    ➀
        files.each { File file ->                               ➁
            if (file.isFile()) {                                ➂
                def size = file.length()                        ➃
                println "** $file.name has length " + size      ➄
            }
        }
    }
}
© 2015-2021, Old Dominion Univ.