Learn the basics of Gradle tasks by running one and looking at its output.

In this section you will:

  • See available tasks

  • Run a task and inspect the results

  • Understand tasks

  • Explore task dependencies

Step 0. Before you Begin

  1. You initialized your Java app in part 1.

Step 1. Viewing available Tasks

A task is a basic unit of work that can be done by Gradle as part of the build.

A task might be responsible for compilation, copying and moving files, creating JAR files, generating Javadoc, publishing artifacts to repositories, or many other discrete units of work.

In the tutorial directory, enter the command below to list all the available tasks in the project:

$ ./gradlew tasks

The list includes tasks contributed by the application plugin and the plugin it applies:

Application tasks
-----------------
run - Runs this project as a JVM application

Build tasks
-----------
assemble - Assembles the outputs of this project.
build - Assembles and tests this project.

...

Documentation tasks
-------------------
javadoc - Generates Javadoc API documentation for the main source code.

...

Other tasks
-----------
compileJava - Compiles main Java source.

...

Tasks are the fundamental building blocks of the build process. Each task represents a specific action that Gradle can perform, and tasks can be combined and ordered based on their dependencies.

For example, the build task you ran in part 1 of the tutorial depends on compileJava, processResources, and test, ensuring that code is compiled, resources are processed, and tests are run before the final build is packaged.

If you want to list the tasks available in a specific subproject, you can use ./gradlew :<subproject name>:tasks. To list the tasks in the app subproject:

$ ./gradlew :app:tasks

You can view more tasks by adding the --all option:

$ ./gradlew tasks --all
$ ./gradlew :app:tasks --all

This shows internal and lifecycle tasks that are normally hidden in the default summary.

Step 2. Understanding Tasks

Tasks can come from several places. Gradle includes some tasks by default, and many others are added automatically when you apply plugins.

If you remember back in part 1, the build script of our Java application applies the application plugin:

app/build.gradle.kts
plugins {   (1)
    // Apply the application plugin to add support for building a CLI application in Java.
    application
}
app/build.gradle
plugins {   (1)
    // Apply the application plugin to add support for building a CLI application in Java.
    id 'application'
}

Applying the application plugin adds tasks like run, build, compileJava, test, and jar.

You can also define your own custom tasks in your build script using the tasks.register() method, and configure what the task does using Gradle’s task APIs.

Gradle provides several built-in task types that make it easy to perform common operations, like copying files, archiving outputs, or running commands.

For example, the Copy task type is used to copy files from one location to another as part of your build.

Here’s how you could register a custom task that copies all .war files from a source directory to a target directory:

app/build.gradle.kts
tasks.register<Copy>("copyTask") {
    from("source")
    into("target")
    include("*.war")
}
app/build.gradle
tasks.register("copyTask", Copy) {
    from("source")
    into("target")
    include("*.war")
}

If this task is defined in the build.gradle(.kts) file for the app subproject, you can run it with:

$ ./gradlew :app:copyTask

Gradle will execute the task and copy any .war files it finds in the source directory into the target directory.

Popular built-in tasks include:

  • Copy - Copy is useful to copy files around.

  • Delete - Delete is useful to delete files and directories.

  • Exec - Exec is useful to execute arbitrary O/S commands.

  • Zip - Zip is useful to bundle files.

With many more documented in the Kotlin and Groovy DSLs.

Step 3. Understanding Dependencies Between Tasks

Often, one task needs another task to run first. For example, a task that creates a JAR file can’t run until the code has been compiled.

If Task B needs the output of Task A, then Gradle must run Task A before it runs Task B. This relationship is called a task dependency.

There are two kinds of task dependencies:

  1. Explicit dependencies: One task directly declares that it depends on another.

  2. Implicit dependencies: Gradle figures out the order automatically because one task uses the output of another (like compiled class files).

Here is an example of explicit task dependency:

app/build.gradle.kts
tasks.register("hello") {
    doLast {
        println("Hello!")
    }
}

tasks.register("greet") {
    doLast {
        println("How are you?")
    }
    dependsOn("hello")
}
app/build.gradle
tasks.register("hello") {
    doLast {
        println('Hello!')
    }
}

tasks.register("greet") {
    doLast {
        println('How are you?')
    }
    dependsOn("hello")
}

In this case, hello prints before greet. The output is Hello! How are you?.

Task execution order is automatically determined by Gradle, taking into account explicit and implicit task dependencies. If there is no dependency between tasks, Gradle enables users to request a specific execution order.

Step 4. Viewing Tasks in the IDE (Optional)

Project tasks are also available in IntelliJ. The project should be open following part 1 of the tutorial.

On the right-hand side of your window, open the Gradle pane to view all available tasks:

intellij idea tasks

Step 5. Running Tasks in the IDE (Optional)

You can run a Gradle task via IntelliJ by double-clicking that task in the pane.

Double-click tutorial > app > build > build.

intellij idea build

Once the build finishes, make sure it is successful in the IntelliJ console:

BUILD SUCCESSFUL in 966ms
7 actionable tasks: 7 executed
3:18:24 AM: Execution finished 'build'.

Step 6. Running Tasks in the Terminal

Run the following command in your terminal:

$ ./gradlew build
> Task :app:compileJava
> Task :app:processResources
> Task :app:classes
> Task :app:jar
> Task :app:startScripts
> Task :app:distTar
> Task :app:distZip
> Task :app:assemble
> Task :app:compileTestJava
> Task :app:processTestResources
> Task :app:testClasses
> Task :app:test
> Task :app:check
> Task :app:build

The build task uses the source code and its dependencies to build the app. As seen in the output, the build task compiles, assembles, tests, and checks the code.

The tasks are printed in order of execution. The jar tasks is a dependency of the build task.

The jar task creates an executable JAR file of the app. Let’s run it by itself:

$ ./gradlew jar
> Task :app:compileJava
> Task :app:processResources
> Task :app:classes
> Task :app:jar

As expected, the compileJava task is a dependency of the jar task and executed first. Once the task finishes, an app.jar file is created in your tutorial/app/build/libs/ folder.

Invoke the run task and check the output:

$ ./gradlew run
> Task :app:compileJava
> Task :app:processResources
> Task :app:classes

> Task :app:run
Hello World!

BUILD SUCCESSFUL in 325ms

The run task executes the code in tutorial/app/src/main/java/com.gradle.tutorial/App.java.

You can take a minute and take a look at the Java code in App.java which simply prints "Hello World" to the screen:

app/src/main/java/org/example/App.java
package org.example;

public class App {
    public String getGreeting() {
        return "Hello World!";
    }
    public static void main(String[] args) {
        System.out.println(new App().getGreeting());
    }
}

Next Step: Dependency Management >>