skip to content

Why do Gradle's own deprecation warnings and configuration-cache problems show up in the Problems Report, and what does that imply for plugin authors?

level: seniorimportance: nice to knowfreq 18%

answer

  1. deprecations + config-cache routed through Problems API
  2. same aggregated report as plugin problems
  3. shared bus: publishers Gradle+plugins, subscribers report+Tooling API
  4. match conventions to sit beside Gradle's section
  5. --warning-mode = enforcement, report = triage

basics

~20 s

Gradle routes its own deprecations and configuration-cache issues through the same Problems API, so they land in the same aggregated report as plugin-reported problems. For authors, it means your problems appear alongside Gradle's, consistently grouped.

solid answer

~50 s

Gradle migrated its internal diagnostics — deprecation warnings and configuration-cache incompatibilities among them — onto the **Problems API**. That means they are reported as structured Problems with a ProblemId rather than plain log lines, so they flow into the **same** aggregated `problems-report.html`, grouped alongside anything plugins report. The implication for plugin authors is twofold: first, your custom problems get the same first-class treatment (grouping, aggregation, locations, solutions, console link) for free; second, you should align with Gradle's model — pick stable ProblemGroups, avoid per-occurrence ids, attach real locations and solutions — so your entries sit consistently next to Gradle's deprecation section. It also reframes deprecation handling: the report becomes the canonical place to see every deprecation before a major upgrade, and `--warning-mode` interacts with how those deprecations are surfaced, while the structured detail still lands in the report.

code

bash · 4 lines
bash
# Deprecations flow into the SAME report; --warning-mode controls escalation, not destination
./gradlew build --warning-mode all   # show each deprecation on console
./gradlew build --warning-mode fail  # fail the build on deprecations (enforcement)
# Either way, structured detail is grouped in build/reports/problems/problems-report.html

go deeper

for a junior

Know that Gradle's deprecations show up in the same report as plugin problems.

for a middle

Explain that deprecations and config-cache issues route through the same Problems API and thus the same aggregated report.

for a senior

Discuss the shared-bus model (publishers vs subscribers), aligning plugin conventions with Gradle's, and --warning-mode as enforcement vs the report as triage.

for a principal

Use the unified report to drive deprecation-readiness for major Gradle upgrades across teams and set conventions for plugin problem reporting.

## One pipeline for all diagnostics Historically Gradle deprecations and configuration-cache problems were just log output. Modern Gradle routes them through the **Problems API** — the same API plugins use. Each becomes a structured Problem with: - a **ProblemId** (group + id), - a **severity** (deprecations are typically WARNING), - a **location**, and - often **solutions** / documentation links. Because they share the pipeline, they share the destination: the aggregated **`build/reports/problems/problems-report.html`**. Open the report and you'll see a "Deprecation" group, possibly a configuration-cache group, and any plugin groups — side by side, each aggregated. ## Why this is deliberate Unifying diagnostics gives consistency: - Users learn **one** place to look for any build problem. - Tooling (IDEs via the Tooling API) gets a **uniform** event stream regardless of whether Gradle or a plugin reported it. - Aggregation works across the board — 500 occurrences of one deprecation collapse to one grouped entry, just like a custom problem would. ## Implications for plugin authors 1. **Free first-class treatment.** Anything you report appears in the same grouped, aggregated, linked report as Gradle's own problems — no extra UI work. 2. **Match the conventions.** Use stable `ProblemGroup`/`ProblemId`, put variable data in location/details, and attach solutions. Then your section reads like Gradle's, not like a foreign blob. 3. **Think upgrade-readiness.** Since deprecations land here, the report is the practical tool for clearing deprecations before, say, an 8.x → 9.0 jump. Encourage teams to read the report, not just the terse console line. ## Interaction with --warning-mode `--warning-mode` (e.g. `all`, `summary`, `fail`) controls how deprecation warnings are surfaced/escalated on the console and whether they fail the build, but the structured problem still flows into the report. So `--warning-mode fail` is your *enforcement* lever while the report remains the *triage* surface. ## Mental model Think of the Problems API as a single bus: Gradle internals and plugins both publish onto it; the HTML report and the Tooling API both subscribe. The report you see is the union, grouped by identity.

  • Does --warning-mode fail stop deprecations from appearing in the report?
    No. --warning-mode controls console escalation and whether the build fails; the structured deprecation problem still flows into the aggregated report.
  • What should a plugin author do so their entries read consistently next to Gradle's?
    Use stable ProblemGroups/ProblemIds, keep variable data in location/details, and attach solutions — mirroring how Gradle reports its own deprecations.

It's like a shared incident board: whether the alert came from the platform team (Gradle) or your team (a plugin), it gets posted to the same board, in the same format, sorted into the same columns.

saying these in an interview costs you the question

  • Thinking deprecations and plugin problems go to separate reports.
  • Believing --warning-mode changes the report's destination rather than console escalation.
  • Assuming you need custom UI to display plugin problems — the shared report handles it.

context

resolving links…