skip to content

Where can you configure Gradle's warning mode, and what wins if both gradle.properties and the command line set it?

level: middleimportance: nice to knowfreq 25%

answer

  1. CLI flag --warning-mode vs property org.gradle.warning.mode
  2. CLI wins over gradle.properties
  3. project file overrides ~/.gradle file
  4. commit fail, override locally with all
  5. exact key: org.gradle.warning.mode

basics

~10 s

Set it via the CLI flag --warning-mode=<mode> or via org.gradle.warning.mode=<mode> in gradle.properties (or as a system property). The command-line flag takes precedence over gradle.properties.

solid answer

~30 s

Two main places: the **CLI** flag `--warning-mode=all|summary|none|fail`, and the **property** `org.gradle.warning.mode=<mode>` set in `gradle.properties` (project or `~/.gradle`) or passed as `-Dorg.gradle.warning.mode=...`/`-Porg...`. When more than one source sets it, the **command-line flag wins** over the properties file, following Gradle's usual precedence where explicit invocation overrides configured defaults. This lets you pin a project-wide default — e.g. `org.gradle.warning.mode=fail` in committed `gradle.properties` so CI and everyone inherit it — while still letting a developer override locally with `--warning-mode all` for a one-off deprecation audit. The home-level `~/.gradle/gradle.properties` is a per-user default that the project file and the CLI both override.

code

bash · 6 lines
bash
# gradle.properties (committed): org.gradle.warning.mode=fail
# Per-invocation override wins for a one-off audit:
./gradlew build --warning-mode all --stacktrace

# Equivalent via property on the command line:
./gradlew build -Dorg.gradle.warning.mode=all

go deeper

for a junior

Know the two places: the --warning-mode flag and org.gradle.warning.mode in gradle.properties.

for a middle

State the precedence (CLI flag beats the file) and the exact property key.

for a senior

Explain the layered-defaults strategy: commit fail, override to all locally for audits.

for a principal

Standardize the committed property across repos for consistent CI/IDE behaviour and document the override workflow.

## The configuration surfaces The warning mode can be set in several layered places, from broadest to most specific: 1. **`~/.gradle/gradle.properties`** — per-user default across all your builds. 2. **Project `gradle.properties`** — committed default for everyone on the project (and CI). 3. **System/Gradle property on the command line** — `-Dorg.gradle.warning.mode=all`. 4. **The dedicated CLI flag** — `--warning-mode=all`. ## Precedence Gradle resolves these with the general rule that **more explicit / closer-to-invocation sources win**. In practice the **`--warning-mode` CLI flag takes precedence** over `org.gradle.warning.mode` from any properties file, and a project `gradle.properties` overrides the home-level one. So a committed `org.gradle.warning.mode=fail` sets the floor for CI, while a developer can still run `--warning-mode all` locally to expand and inspect, without editing files. ```bash # Project gradle.properties: org.gradle.warning.mode=fail # This local run overrides it to audit deprecations in detail: ./gradlew build --warning-mode all --stacktrace ``` ## Why this layering is useful for upgrades - **Committed `fail`** keeps the project continuously clean (the ratchet) without depending on each person remembering a flag. - **CLI override to `all`** is the audit tool: when the ratchet does trip, you switch to `all --stacktrace` for one run to locate the offenders, fix them, and let the committed `fail` resume. - **Home-level default** is handy for a developer who wants `all` everywhere locally, while project files still decide CI behaviour. ## Pitfalls - Forgetting that the CLI flag overrides the file — people sometimes set `fail` in `gradle.properties` and then wonder why a colleague's `--warning-mode none` run didn't fail; the colleague explicitly overrode it. - Mixing the property name up: it's `org.gradle.warning.mode`, not `warning.mode` or `gradle.warningMode`. - Expecting the IDE to honour a CLI flag — IDEs read the properties file or their own settings, so commit the property for IDE consistency.

  • What is the exact property key for the warning mode?
    `org.gradle.warning.mode`, set in `gradle.properties` or passed as `-Dorg.gradle.warning.mode=<mode>`.
  • If gradle.properties says fail but a developer runs --warning-mode none, what happens?
    The CLI flag wins, so that run uses `none` and won't fail on deprecations — the explicit invocation overrides the committed default for that command only.
  • Why commit the property rather than rely on CLI flags?
    A committed `org.gradle.warning.mode` is inherited by CI, IDEs, and every developer without anyone remembering to type a flag, making the default consistent.

saying these in an interview costs you the question

  • Claiming gradle.properties overrides the CLI flag (it's the reverse).
  • Using a wrong property name like gradle.warningMode.
  • Assuming an IDE picks up a one-off CLI flag instead of the committed property.

context

resolving links…