skip to content

How do you enable configuration on demand, and what's the difference between the command-line flag and the gradle.properties setting?

level: juniorimportance: should knowfreq 25%

answer

  1. --configure-on-demand / --no-configure-on-demand
  2. org.gradle.configureondemand=true
  3. flag = per-run, property = default
  4. root vs ~/.gradle gradle.properties
  5. flag overrides property

basics

~10 s

Use --configure-on-demand on the command line for a single build, or set org.gradle.configureondemand=true in gradle.properties to make it the default for every build of that project.

solid answer

~40 s

There are two switches for the same feature. The **command-line flag** `--configure-on-demand` (with a `--no-configure-on-demand` counterpart) enables it for that one invocation only — handy for trying it out or for a CI job that targets a narrow task set. The **`gradle.properties` property** `org.gradle.configureondemand=true` makes it the default for the build; placed in the project's root `gradle.properties` it applies to everyone, while in `~/.gradle/gradle.properties` it applies to all of that user's builds. The flag overrides the property for the current run. Because the feature is a heuristic that can misbehave with cross-project configuration, teams usually only commit the property after verifying their build doesn't rely on `allprojects`/`subprojects` wiring.

code

bash · 5 lines
bash
# enable for one build
gradle :app:assemble --configure-on-demand

# disable for one build even if gradle.properties turns it on
gradle build --no-configure-on-demand

go deeper

for a junior

Name both switches: the --configure-on-demand flag and org.gradle.configureondemand=true.

for a middle

Explain precedence (flag overrides property) and where the property lives (project vs user gradle.properties).

for a senior

Note the caution about committing it only after verifying no cross-project configuration dependence.

for a principal

Position it among standard performance toggles and decide team defaults vs per-developer overrides via GRADLE_USER_HOME.

## Two ways to turn it on Configuration on demand is a **build-wide mode**, not a per-task or per-module setting. You control it in two places: ### 1. Command-line flag (per-invocation) ```bash gradle :app:test --configure-on-demand # explicitly disable for one run, overriding gradle.properties: gradle build --no-configure-on-demand ``` The flag affects only the current invocation. Use it to experiment, or in a specific CI job that runs a narrow slice of the build. ### 2. `gradle.properties` (persistent) ```properties org.gradle.configureondemand=true ``` Property resolution precedence (later wins): - `GRADLE_USER_HOME/gradle.properties` (`~/.gradle/…`) — affects **all** of a user's builds. - Project root `gradle.properties` (checked into VCS) — affects **everyone** on the project. - Command-line `-P` / system properties / the dedicated flag — affect the current invocation. So a committed project property sets the team default, and an individual can still override per-run with `--no-configure-on-demand`. ## Where it commonly lives The same `gradle.properties` file typically also carries sibling performance toggles: ```properties org.gradle.parallel=true org.gradle.caching=true org.gradle.configureondemand=true ``` (These are independent features; enabling one doesn't enable the others.) ## Verifying it's active Run with `--info`; Gradle logs that it is configuring projects on demand and which projects it evaluates. If you see *all* projects being configured for a narrow task, either the mode is off or your build's cross-project wiring forces full configuration. ## Practical guidance Don't commit the property blindly. First confirm the build doesn't depend on cross-project configuration (`allprojects {}`, `subprojects {}`, reaching into `project(":x").tasks`). If it does, configure-on-demand can produce wrong or incomplete task graphs, and the property should stay off until the build is refactored.

  • If gradle.properties sets it true but you pass --no-configure-on-demand, what happens?
    The command-line flag wins for that invocation — configuration on demand is disabled for that run only.
  • Where would you put the property to affect every build on your machine but not commit it for the team?
    In `~/.gradle/gradle.properties` (GRADLE_USER_HOME), which is per-user and not part of the project repo.

saying these in an interview costs you the question

  • Saying it's enabled per-task or per-module — it is a single build-wide mode.
  • Forgetting that the command-line flag overrides the gradle.properties value.

context

resolving links…