skip to content

What is the `htmlDependencyReport` task and how does it behave in a multi-project build?

level: middleimportance: should knowfreq 38%

answer

  1. HTML, interactive, searchable
  2. selection reasons shown
  3. root-applied -> aggregates subprojects
  4. single report, project selector
  5. build/reports/project/dependencies

basics

~10 s

htmlDependencyReport (from project-report) generates a browsable HTML report of resolved dependencies. In a multi-project build it aggregates every subproject into one report with a project selector.

solid answer

~40 s

`htmlDependencyReport` is a task added by the `project-report` plugin that renders the dependency graph as navigable HTML rather than console text. For each configuration it shows the resolved versions and lets you expand the tree, search, and see why a version was selected. Its distinguishing feature is aggregation: when applied to the root of a multi-project build, it produces a single report covering all subprojects, with a drop-down to switch between them — far more practical than running the console `dependencies` task in each subproject. Output goes under `build/reports/project/dependencies/` by default. You typically apply `project-report` to the root and run `./gradlew htmlDependencyReport` to get the consolidated artifact, which CI can archive.

code

bash · 3 lines
bash
# apply project-report at the root, then:
./gradlew htmlDependencyReport
# open build/reports/project/dependencies/index.html

go deeper

for a junior

Know it produces an HTML dependency report instead of console text.

for a middle

Explain root-level multi-project aggregation and the single report with a project selector.

for a senior

Discuss CI artifact publishing, that it resolves configurations, and relocating output via ReportingExtension.

for a principal

Compare with build scans / Develocity for org-wide dependency observability and decide which to standardize on.

## Purpose The console `dependencies` task is great for a single project but awkward at scale: large trees scroll off-screen and you must run it project by project. `htmlDependencyReport`, contributed by the `project-report` plugin, solves both problems by producing an interactive HTML artifact. ## What the report contains - A list of the project's **configurations** (e.g. `compileClasspath`, `runtimeClasspath`). - The **resolved dependency tree** per configuration, expandable/collapsible. - **Selection reasons** — why a particular version won (conflict resolution, constraint, forced version). - A **search box** to find a coordinate across the graph. ## Multi-project aggregation The key behavior: applied at the **root project**, `htmlDependencyReport` walks all subprojects and emits **one** report with a project selector. So a single `./gradlew htmlDependencyReport` run gives you a consolidated, browsable view of the entire build's dependencies. This is the main reason teams reach for it over the per-project console task. ```kotlin // root build.gradle.kts plugins { id("project-report") } ``` Run: `./gradlew htmlDependencyReport` → open `build/reports/project/dependencies/index.html`. ## Output location Default is under the project's `build/reports/`. Like other reporting tasks it respects the `ReportingExtension` base directory, so `reporting { baseDirectory.set(...) }` can relocate it. ## CI usage Because it is a self-contained set of HTML/JS files, CI can publish it as an artifact, giving reviewers a clickable dependency view per build without re-running Gradle. ## Caveats It **resolves** configurations to build the tree, so it triggers dependency resolution (network/cache access) and can be slower than a metadata-only task. It is a reporting task, not part of the normal `build` lifecycle, so it runs only when requested or via `projectReport`/`buildDashboard`.

  • Why might you prefer htmlDependencyReport over the console `dependencies` task in CI?
    It produces a single aggregated, browsable, searchable artifact across all subprojects that CI can publish, instead of scattered console output you'd have to run per project.
  • Does generating the report trigger dependency resolution?
    Yes — it resolves the configurations to build the tree, so it accesses the dependency cache/network and is not purely a metadata operation.

saying these in an interview costs you the question

  • Claiming it requires running once per subproject — root application aggregates them.
  • Saying it does not resolve dependencies — it must resolve to render the tree.
  • Confusing it with a build-scan dependency view (a separate Develocity feature).

context

resolving links…