skip to content

A summary footer says deprecated features were used. How do you find exactly what is deprecated and where it comes from?

level: middleimportance: must knowfreq 50%

answer

  1. summary only points, all diagnoses
  2. --warning-mode all
  3. --stacktrace for hidden plugin source
  4. fix upstream if plugin
  5. commit all to stay visible

basics

~10 s

Re-run the build with --warning-mode all to print each deprecation message and its source. Add --stacktrace to trace the exact build-script or plugin call that triggered it.

solid answer

~40 s

The default `summary` mode only tells you that *some* deprecation occurred. To diagnose, re-run with `--warning-mode all`, which prints each deprecation's full message and usually the location that triggered it. If the message doesn't make the source obvious — common when the warning originates inside a plugin — add `--stacktrace` so Gradle prints the call stack pinpointing which build-script line or plugin invoked the deprecated API. From there you decide ownership: if it's your build logic, fix the call; if it's a plugin, check for a newer plugin version, since the fix usually lives upstream. Running with `all` regularly (e.g. via `org.gradle.warning.mode=all` in committed `gradle.properties`) keeps these visible so they're addressed incrementally rather than discovered all at once during an upgrade.

code

bash · 5 lines
bash
# 1. Surface every deprecation
./gradlew build --warning-mode all

# 2. If the source is unclear (e.g. inside a plugin), get the call stack
./gradlew build --warning-mode all --stacktrace

go deeper

for a junior

Know to re-run with --warning-mode all to see the actual warnings.

for a middle

Add --stacktrace to locate plugin-sourced warnings and reason about ownership of the fix.

for a senior

Establish committed org.gradle.warning.mode=all so deprecations are addressed incrementally, not at upgrade time.

for a principal

Drive a triage process distinguishing build-owned vs plugin-owned deprecations across many repos, with upgrade SLAs for plugins.

## Why summary isn't enough The default `summary` mode deliberately collapses warnings into a single footer like: ``` Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. You can use '--warning-mode all' to show the individual deprecation warnings... ``` That's a pointer, not a diagnosis. It tells you *that* something is deprecated but not *what* or *where*. ## Step 1 — switch to `all` ```bash ./gradlew build --warning-mode all ``` Now each deprecation prints in full, e.g. naming the deprecated method, what replaces it, and frequently the build-script line that triggered it. ## Step 2 — add `--stacktrace` for hidden sources When a warning comes from inside a plugin or applied script, the message alone may not reveal the trigger. Add a stacktrace: ```bash ./gradlew build --warning-mode all --stacktrace ``` The stack reveals the call chain — you can see whether the deprecated API was invoked by your `build.gradle.kts`, by a convention plugin, or by a third-party plugin. ## Step 3 — assign ownership and fix - **Your build logic:** rewrite the call to the recommended replacement named in the message. - **Third-party plugin:** the fix lives upstream. Upgrade the plugin; if no fixed version exists, track it and avoid fail-mode until it ships. ## Keep it visible Committing `org.gradle.warning.mode=all` in `gradle.properties` means every local build surfaces deprecations continuously, so they're whittled down incrementally instead of avalanching during the next major upgrade.

  • Why doesn't summary mode help you fix the deprecation?
    It only prints a footer count saying deprecated features were used; it doesn't list which API or where, so you can't act on it without switching to all.
  • The warning comes from a plugin you depend on — what do you do?
    The fix is upstream: upgrade to a plugin version that no longer uses the deprecated API, or track the issue and hold off on fail-mode until it ships.

saying these in an interview costs you the question

  • Trying to fix a plugin's deprecation by editing your own build script when the call originates inside the plugin.
  • Expecting summary mode to name the offending API.

context

resolving links…