skip to content

Diagnostic Report Tasks

4 roadmaps5 questions

The built-in dependencies, dependencyInsight, buildEnvironment, outgoingVariants, and resolvableConfigurations reports. Interviewers ask because knowing dependencyInsight is the difference between explaining a selected version and guessing at it.

on this pageshow

explore

questions

5

What does the built-in `dependencies` task do, and how do you scope it to a single configuration?

level: juniorimportance: must knowfreq 72%

answer

  1. ASCII tree per configuration
  2. --configuration runtimeClasspath to scope
  3. 1.0 -> 1.2 = conflict resolution
  4. (*) omitted subtree, (c) constraint, (n)/FAILED
  5. diagnostic task, builds nothing

basics

~10 s

gradle dependencies prints the resolved dependency trees for each configuration. Use --configuration <name> (e.g. runtimeClasspath) to limit the output to one configuration instead of dumping every one.

solid answer

~40 s

The `dependencies` task is a built-in *diagnostic* task on every project. Running `gradle dependencies` renders, per configuration, the full resolved dependency graph as an ASCII tree — direct deps, their transitive deps, and resolution annotations. Because a typical project has many configurations (`compileClasspath`, `runtimeClasspath`, `testRuntimeClasspath`, …), the unfiltered output is huge, so in practice you almost always pass `--configuration runtimeClasspath` to focus. The tree marks conflict resolution with arrows (`1.0 -> 1.2`), shows `(*)` where a subtree was already printed and omitted, `(c)` for constraints, and `(n)` for not-resolved. It reflects *resolved* versions, so it's the first tool you reach for to understand why a particular version ended up on the classpath.

code

bash · 5 lines
bash
# All configurations (verbose)
gradle dependencies

# Just the runtime classpath of the :app subproject
gradle :app:dependencies --configuration runtimeClasspath

go deeper

for a junior

Know that gradle dependencies prints dependency trees and --configuration runtimeClasspath narrows it.

for a middle

Read the annotations fluently — -> conflict, (*) omitted, (c) constraint — and pick the right configuration.

for a senior

Use it as the first triage step for classpath/version-skew bugs and explain when to escalate to dependencyInsight.

for a principal

Promote it as a debugging convention in the org; pair with constraints/platforms so reports are deterministic and reviewable.

## What it is `dependencies` is one of Gradle's built-in **diagnostic report tasks** — tasks Gradle adds to every project to let you inspect the build model from the CLI without writing any code. It does not build anything; it resolves and *prints* dependency graphs. ## What it shows For each *configuration* (a named, typed bucket of dependencies such as `compileClasspath` or `runtimeClasspath`), it prints an indented tree: - **Direct dependencies** declared in your `dependencies { }` block. - **Transitive dependencies** pulled in by those. - **Resolution annotations** that explain what the resolver did. Key annotations: - `1.0 -> 1.2` — version **conflict resolution**: something requested 1.0 but the graph settled on 1.2. - `(*)` — this module's subtree was already shown elsewhere and is **omitted** to keep output small. - `(c)` — the entry comes from a dependency **constraint**, not a direct/transitive edge. - `(n)` — **not resolved** (e.g. a configuration that isn't resolvable). - `FAILED` — resolution failed for that node. ## Scoping the output Unfiltered output lists *every* configuration and is overwhelming. Filter with: ```bash gradle dependencies --configuration runtimeClasspath ``` In a multi-project build, target a subproject path: `gradle :app:dependencies --configuration runtimeClasspath`. ## Why it matters It answers "which version of X actually made it onto the classpath, and who brought it in?" — the starting point for debugging version skew, duplicate classes, and `NoSuchMethodError`s caused by an unexpected transitive bump. For "why this *specific* version?" you escalate to `dependencyInsight`.

  • What does an arrow like `com.google.guava:guava:30.0 -> 32.1.3` in the tree mean?
    Conflict resolution: some node requested 30.0 but Gradle's resolution strategy selected 32.1.3 (typically highest-version-wins), so 32.1.3 is what ends up on the classpath.
  • Why might `dependencies` output be enormous and how do you tame it?
    It prints every configuration's full tree. Scope with `--configuration <name>`; the `(*)` markers also collapse already-printed subtrees to reduce size.

saying these in an interview costs you the question

  • Claiming the task downloads/compiles code — it only resolves and reports.
  • Thinking the tree shows *requested* versions; it shows *resolved* (post-conflict-resolution) versions.
  • Forgetting `--configuration` and being unable to read the wall of output.

context

resolving links…

open as a page

When and how do you use `dependencyInsight`, and how does it differ from `dependencies`?

level: middleimportance: must knowfreq 68%

basics

~20 s

dependencyInsight traces why one specific module is on the classpath and which version won. You run gradle dependencyInsight --dependency <name> --configuration <name>. dependencies shows the whole tree; dependencyInsight is a focused, reverse view of one dependency.

open as a page

What do the built-in `properties` and `projects` tasks report, and how do they help inspect the build model from the CLI?

level: juniorimportance: should knowfreq 40%

basics

~20 s

gradle properties prints the project's properties (name, group, version, plus extra/ext and many built-ins). gradle projects prints the project hierarchy of a multi-project build as a tree with each subproject's path. Both are read-only model inspectors.

open as a page

What does the `buildEnvironment` task report, and why is it distinct from `dependencies`?

level: middleimportance: should knowfreq 45%

basics

~20 s

buildEnvironment prints the dependency tree of the buildscript classpath — the plugins and libraries used to configure the build itself, from buildscript { dependencies { classpath … } }. dependencies covers your application's configurations instead.

open as a page

What do `outgoingVariants` and `resolvableConfigurations` report, and when would you use each?

level: seniorimportance: should knowfreq 38%

basics

~20 s

outgoingVariants lists what your project publishes/exposes to consumers — the consumable configurations, their attributes, and artifacts. resolvableConfigurations lists what your project consumes — the resolvable configurations and the attributes they request. Together they explain variant-aware resolution.

open as a page