skip to content

You run with --warning-mode all and see a deprecation, but the message doesn't point at your build script. How do you find what actually triggered it?

level: middleimportance: should knowfreq 45%

answer

  1. --warning-mode all + --stacktrace
  2. origin is often a plugin, not your script
  3. first non-gradle frame = the trigger
  4. fix = upgrade that plugin
  5. tee to a file, grep distinct origins

basics

~10 s

Add --stacktrace to the run. Combined with --warning-mode all, Gradle prints a stack trace for each deprecation, so you can see whether it came from your build script or from a plugin.

solid answer

~40 s

Run `--warning-mode all --stacktrace`. With `all`, each deprecation is printed where it happens; adding `--stacktrace` attaches the call stack so you can see the **origin**. Many deprecations don't come from your own `build.gradle(.kts)` — they come from a **plugin** calling a deprecated Gradle API. The stack trace shows the plugin class in the frames, which tells you the fix is usually *upgrade that plugin* (or report it upstream), not edit your script. For the noisiest cases you can also crank logging with `--info` or `--debug`, but `--stacktrace` is the targeted tool. The practical loop is: run with `all --stacktrace`, read the top application/plugin frames, map each to a plugin or a DSL call you own, fix, and re-run until clean. Wiring `--warning-mode fail` afterwards stops regressions.

code

bash · 5 lines
bash
# See each deprecation with its call stack and capture for triage
./gradlew assemble --warning-mode all --stacktrace 2>&1 | tee deprecations.txt

# Then grep the file for distinct plugin packages to find upgrade candidates
grep -E 'at (com|org)\.' deprecations.txt | sort -u | head

go deeper

for a junior

Know that adding --stacktrace shows where a deprecation came from.

for a middle

Read the trace to distinguish your-script vs plugin origin and map a plugin package to the dependency to upgrade.

for a senior

Capture output, triage distinct origins, and choose plugin upgrades vs DSL rewrites; finish with fail in CI.

for a principal

Drive a repeatable upgrade-audit process across many repos: standardize the all --stacktrace audit, track plugin-origin deprecation debt, and coordinate upstream plugin fixes.

## Why the message alone isn't enough A deprecation warning text tells you *what* is deprecated ("The X method has been deprecated...") but often not *who* called it. In a real build the caller is frequently a third-party plugin, because plugins are themselves consumers of the Gradle API. Without the origin you can waste time scouring your own scripts for a call you never wrote. ## --stacktrace is the locator `--stacktrace` (or `-s`) makes Gradle attach a Java stack trace to messages, including deprecation warnings when `--warning-mode all` is active. Read the trace top-down: - Frames inside `org.gradle...` are Gradle internals reporting the deprecation. - The first frame that belongs to **your** code or a **plugin package** (e.g. `com.android.build...`, `org.springframework.boot...`) is the trigger. - That package name maps directly to the dependency/plugin you must upgrade. `--full-stacktrace` (`-S`) is the even more verbose variant that keeps internal frames too — rarely needed. ## Putting it together ```bash ./gradlew assemble --warning-mode all --stacktrace 2>&1 | tee deprecations.txt ``` Capturing to a file lets you grep for distinct origins and triage them. A common outcome: three of five deprecations are the same plugin, so one plugin bump clears them. The remaining ones are genuine DSL usages in your build that you rewrite to the non-deprecated form. ## Relationship to fixing The goal isn't to silence warnings (`none`) but to *eliminate the cause* so the build is clean and forward-compatible. After clearing, switch CI to `--warning-mode fail` so any re-introduction — yours or from a future plugin upgrade — turns the build red immediately. ## Note on scope This is the upgrade-context use of the flags. The general `--stacktrace`/logging reference for everyday error debugging is covered elsewhere; here the point is tracing **deprecations** ahead of a major-version removal.

  • If three deprecations all trace back to one plugin, what's the cheapest fix?
    Upgrade that single plugin to a version that uses the non-deprecated APIs — one bump usually clears all three rather than editing the build script.
  • What's the difference between --stacktrace and --full-stacktrace?
    `--stacktrace` (`-s`) trims Gradle-internal frames to keep the trace readable; `--full-stacktrace` (`-S`) keeps everything including internals, which is rarely needed for locating a deprecation origin.
  • Why not just set --warning-mode none if the warnings are from a plugin you don't control?
    `none` hides the deprecation but the underlying API still gets removed at the next major, so the build will break then. You need the plugin fixed/upgraded, not the symptom muted.

saying these in an interview costs you the question

  • Assuming every deprecation originates in your own build script.
  • Reaching for --warning-mode none to make plugin-origin warnings 'go away'.
  • Not realizing --stacktrace is what attaches origin info to the deprecation message.

context

resolving links…