skip to content

Which built-in report tasks help you understand a project from the command line, and what does each tell you?

level: middleimportance: must knowfreq 65%

answer

  1. tasks --all to see everything
  2. dependencies --configuration
  3. dependencyInsight = why this version
  4. properties dumps values
  5. help --task <name>

basics

~10 s

Run tasks to list available tasks, dependencies to print the dependency tree, properties to dump project properties, and help for general help or help --task <name> for details on a specific task.

solid answer

~40 s

Gradle ships diagnostic report tasks you invoke like any task. `gradle tasks` lists the runnable tasks grouped by category (`--all` shows hidden/lifecycle tasks too). `gradle dependencies` prints the resolved dependency graph per configuration; narrow it with `--configuration runtimeClasspath`, and use `gradle dependencyInsight --dependency <name>` to explain *why* a particular version was chosen (conflict resolution, who pulled it in). `gradle properties` dumps all project properties and their values — handy for checking what a property resolved to. `gradle help` prints top-level help, and `gradle help --task build` describes a specific task's path, type, and options. These are read-only introspection tools; they don't run your application code. In a multi-project build, prefix with the path, e.g. `gradle :app:dependencies`.

code

bash · 7 lines
bash
./gradlew tasks --all
./gradlew dependencies --configuration runtimeClasspath
./gradlew dependencyInsight --dependency jackson-databind --configuration runtimeClasspath
./gradlew properties
./gradlew help --task test
# multi-project: target a subproject
./gradlew :app:dependencies

go deeper

for a junior

Name tasks/dependencies/help and what each broadly does.

for a middle

Use --all, --configuration, and dependencyInsight correctly; know properties dumps resolved values.

for a senior

Reach for dependencyInsight to diagnose version conflicts and explain the tree annotations ((*), ->, (n)); address multi-project addressing.

for a principal

Promote these as the first-line, shareable diagnostics in code review and CI (e.g. capturing dependencies output for audit), reducing reliance on noisy --debug logs.

## Built-in report tasks Gradle exposes several **diagnostic report tasks** — ordinary tasks whose job is to introspect the build. You run them like anything else (`./gradlew <task>`), and they're read-only. ### `tasks` Lists the tasks you can run, grouped (Build, Verification, Documentation, etc.): ```bash ./gradlew tasks # grouped, user-facing tasks ./gradlew tasks --all # include rules + tasks without a group ./gradlew tasks --group build ``` Use it to discover what a project (or applied plugin) offers. ### `dependencies` Prints the resolved dependency tree for each configuration: ```bash ./gradlew dependencies --configuration runtimeClasspath ``` Annotations in the tree tell a story: `(*)` = subtree omitted (shown elsewhere), `->` = version selected by conflict resolution, `(n)` = not resolved (a *declarable*-only configuration). Pair it with **`dependencyInsight`** to answer "why this version?": ```bash ./gradlew dependencyInsight --dependency slf4j-api --configuration runtimeClasspath ``` This traces the resolution path and the rule that picked the version. ### `properties` Dumps every project property and its current value (including those set via `-P`, `gradle.properties`, or convention): ```bash ./gradlew properties ``` Great for verifying what a property actually resolved to at configuration time. ### `help` The default task. With `--task` it describes a specific task — its fully-qualified path, type, and CLI options: ```bash ./gradlew help --task build ``` ## Multi-project addressing In a multi-project build, target a subproject by path: ```bash ./gradlew :app:dependencies :lib:tasks ``` ## Why they matter as CLI diagnostics Before reaching for `--info`/`--debug`, these tasks often answer the question directly: *what can I run?* (`tasks`), *what's on my classpath and why?* (`dependencies`/`dependencyInsight`), *what did this property resolve to?* (`properties`). They're the structured, human-readable counterpart to raising the log level.

  • How do you find out WHY a specific dependency version was selected?
    Run `dependencyInsight --dependency <name> --configuration <cfg>`. It traces who requested the module and shows the conflict-resolution decision that picked the final version.
  • Why might `gradle tasks` not show a task you know exists?
    By default `tasks` only lists tasks with a group (user-facing ones). Tasks without a group, or those created by rules, are hidden until you add `--all`.
  • How do you run a report task against one subproject in a multi-project build?
    Prefix with the project path, e.g. `./gradlew :app:dependencies`. Without a path it runs against the project in the current directory (and, for some tasks, aggregates).

saying these in an interview costs you the question

  • Saying `gradle tasks` shows every task by default — it hides ungrouped tasks unless you pass --all.
  • Confusing `dependencies` (the whole tree) with `dependencyInsight` (one dependency's why).
  • Thinking these tasks execute application code — they're read-only introspection.

context

resolving links…