# Part 2: Running Gradle Tasks

version 8.14.1

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:

## 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.

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 >>