gradle-task-tree: printing Gradle task dependency trees from the console

A taskTree task that prints instead of running

gradle-task-tree is a Gradle plugin that adds a taskTree task which prints the task dependency tree report to the console. The tree is printed with a format similar to the built-in dependencies task.

The invocation pattern is the whole interface.

gradle <task 1>...<task N> taskTree

And the behaviour is worth reading carefully. When one of the tasks given to the gradle command is taskTree, executions of all other tasks are skipped. Instead, their task dependency tree is printed.

That is the design decision that makes this a debugging tool rather than a reporting task bolted on. You can add taskTree alongside build or test without those tasks running, so inspecting the graph is free of the cost of executing it. On a build where the compilation takes minutes, that matters.

The output format is the familiar ASCII tree. For gradle build taskTree you get the assemble and check branches under build, with jar and classes, compileJava and processResources, testClasses and compileTestJava, all drawn with the box drawing characters.

The trivial case is handled too. Running gradle compileJava taskTree prints the task and the line No task dependencies, which is the answer you want when you suspected a task was pulling in nothing and were right.

And multiple tasks can be named at once, in which case each gets its own tree printed with a blank line between them.

Two ways to apply it: the plugins block or an init script

The plugin can be configured in the build script or in an init script, and the readme gives the snippets for both.

The build script route is the plugins block in the Groovy DSL.

plugins {
    id "com.dorongold.task-tree" version "4.0.2"
}

And there is an equivalent for the Kotlin DSL.

plugins {
    id("com.dorongold.task-tree") version "4.0.2"
}

The init script route is for applying it to all your projects at once. You put the following in a file named init.gradle in the $USER_HOME/.gradle/ directory, or any file ending in .gradle in the $USER_HOME/.gradle/init.d/ directory.

initscript {
    repositories {
        maven { url "https://plugins.gradle.org/m2" }
    }
    dependencies {
	    classpath "com.dorongold.plugins:task-tree:4.0.2"
    }
}
rootProject {
    apply plugin: com.dorongold.gradle.tasktree.TaskTreePlugin
}

Note the coordinate difference between the two routes. The plugins block uses the plugin marker id com.dorongold.task-tree, while the init script puts com.dorongold.plugins:task-tree on the classpath and applies the plugin class by its fully qualified name, com.dorongold.gradle.tasktree.TaskTreePlugin.

The plugin is published on the Gradle Plugin Portal under com.dorongold.task-tree, and the init script adds the plugin portal's own m2 repository to the initscript repositories block, which is what makes that classpath resolution work.

The init script route is the one to reach for when the question is not about one project. If a task you did not write is taking a long time, and you do not control the build file, the init script is the only way to get the tree.

Configuration for depth, inputs, outputs and repeated subtrees

The command line options control what the tree shows, and there is a matching static configuration for projects where you want the same output every time.

The command line options are --depth with a number to limit the printed tree depth, --with-inputs to print task inputs for each task, --with-outputs to print task outputs, --with-description to print the task description, and --repeat to allow a sub-tree of the same task to be repeated more than once.

The static form goes into build.gradle, or into init.gradle if you took that route, and is written as a configure block on the named task.

tasks.named('taskTree').configure {
    depth = 3
    withInputs = true
    withOutputs = true
    withDescription = true
    repeat = true
    impliesSubProjects = true
}

The colour choices are worth knowing because they are what make the output readable in a long tree. Task inputs are printed in red just below the task, task outputs in green, and the task description in orange.

The impliesSubProjects property is the one with a non-obvious name and a direct effect. Setting it to true disables printing the task tree for child projects in a multi-project, which is how you keep a composite build from printing the same subtree once per subproject.

Which is relevant because of the note in the readme about multi-project builds: it is recommended to apply the plugin on the root project only. The taskTree task will automatically be added to child projects, so it is unnecessary to apply this plugin under allprojects or subprojects.

That advice saves a real annoyance. Applying it under allprojects is the obvious thing to do when you want the task everywhere, and it is exactly what produces duplicated output.

Version compatibility and what the older releases cover

The compatibility section is short and specific: Gradle 7.6+ and Java 1.8+ for the current line, with older branches documented separately.

Version 3.0.0 of the plugin is compatible with Gradle 6.8 to 7.5.1, and version 1.5 is compatible with Gradle 2.3 to 6.7.1. That is the practical way to read the table: if you are on Gradle 6 or 7.5, you are on an old plugin version, not on a broken current one.

The release history shows how the plugin has moved: 4.0.0 on 2024-06-11, 4.0.1 on 2025-03-08 and 4.0.2 on 2026-08-08. The last push was on 2026-08-08, the same day as the 4.0.2 release, so the tree and the published version match.

The licence field on the repository says Apache-2.0, with a LICENSE file at the root. The topic list on the repository contains a single entry, gradle-plugin, which is an accurate summary of the scope.

There is also an IntelliJ route, and it is worth knowing it exists because it changes where you would look. The reveal-dependency-plugin from jvmlet can print the task dependency tree inside IntelliJ, so if you want the tree in the IDE rather than in a terminal, that is a separate project to evaluate.

The repository itself is small and conventional: a build.gradle and settings.gradle at the root, the gradle wrapper, a src/ directory, a CHANGELOG.md, a .github/ directory, and a .claude/ directory.

Where gradle-task-tree is the wrong tool

Two limits, and the first one is about output rather than capability.

The output is a text tree in a terminal. There is no GUI, no graphical node graph, no way to click a task and see what depends on it in the other direction. For a small build, the built-in dependencies task and a good understanding of your own build script are often enough, and the plugin adds a dependency for a nicer format of information you already roughly have. The value grows with the size of the build, where the dependency graph of a single task can have a dozen branches and no human remembers them.

The second limit is the direction of the information. The tree shows what a task depends on, not what depends on a task. When a build is slow you usually want the first question answered, which is what pulls in the work I did not ask for. But when you want to know what will be affected by changing a task, or which of forty modules depends on the one you are about to touch, this tool does not answer that, because Gradle's task graph is queried in one direction.

The third practical limit is the multi-project behaviour, which the readme handles but a user has to know about. Applying the plugin under allprojects is the natural instinct and produces repeated output, because the taskTree task is added to child projects automatically. The fix is documented, but it is a case of a plugin whose convenience footgun has to be understood before it is used in a large build.

The alternatives split by what you need. Gradle's own dependencies task already shows dependency information, though in a different format and not as a tree. The --dry-run option on any Gradle command prints the execution plan for a task without running it, which covers the question of what would run, though not the full transitive picture. A tool such as Gradle Doctor or a build scan service gives a richer, often graphical view at the cost of running the build and sending data off the machine. And the IntelliJ reveal-dependency-plugin does the same job inside the IDE.

Editorial conclusion

gradle-task-tree suits a developer on a large multi-project Gradle build who needs to see what a task actually pulls in before running it, and the depth limit and the with-inputs, with-outputs and with-description options make it useful for diagnosing a build that is slower or noisier than expected. It does not suit someone who wants a live graphical view, since the output is a text tree in the console, and it does not suit an older Gradle build without checking the compatibility table. Before adopting it, confirm your Gradle version is 7.6 or newer, and apply the plugin to the root project only, since applying it under allprojects or subprojects is explicitly unnecessary.

Frequently asked questions

Official sources

1. dorongold/gradle-task-tree on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases