Creating Custom Gradle Tasks with the Groovy DSL

Open the build.gradle file and append a simple task definition that prints messages during the configuration phase and inside a doLast block.

println "1"

task howdy {
    println "2"
    doLast {
        println "Howdy"
    }
}

println "3"

Run the task with ./gradlew howdy. The output shows the configuration prints (1, 2, 3) and, after the task executes, the message "Howdy" from the doLast block.

The Configure project phase runs all top‑level statements, while the doLast closure runs only when the task itself is invoked.

Adding a second custom task demonstrates task ordering:

task partner {
    println "4"
    doLast {
        println "Partner"
    }
}
println "5"

Executing ./gradlew partner prints the configuration numbers 1‑5 and then "Partner".

To make one task depend on another, add a line such as partner.dependsOn howdy to the script and run ./gradlew partner. Gradle will first execute howdy and then partner.

The same relationship can be expressed with howdy.finalizedBy partner, which runs partner after howdy completes.

In practice, custom tasks often extend existing task types. For example, a copy task that copies documentation files can be defined as:

task copyDocs(type: Copy) {
    from 'src/main/doc'
    into 'build/target/doc'
}

More advanced copy tasks can filter files, rename them, or exclude patterns such as .DS_Store:

task copyDocs(type: Copy) {
    from 'src/main/doc'
    into 'build/target/doc'
    eachFile { file ->
        doSomething(file);
    }
    exclude '**/.DS_Store'
}

Packaging tasks like jar and war, as well as Spring Boot's bootJar and bootWar, inherit the flexibility of the Copy task, allowing full control over the build artefacts.

For further details, consult the Gradle documentation and API reference.