skip to content

A developer runs `./gradlew tst` and gets an error; another runs `./gradlew comp` and gets a different error. How does Gradle resolve a task selector, and what are the failure modes for an unmatched or ambiguous name?

level: middleimportance: should knowfreq 35%

answer

  1. exact match -> then abbreviation
  2. no match = 'task not found' + did-you-mean
  3. many abbreviation hits = 'ambiguous' + candidates
  4. fan-out across subprojects is NOT an error
  5. diagnose with `tasks`, `help --task`

basics

~20 s

Gradle tries to match the selector as an exact name, then as a camelCase abbreviation. If nothing matches you get a 'task not found' error (often with did-you-mean suggestions); if the abbreviation matches several tasks you get an 'ambiguous abbreviation' error listing candidates.

solid answer

~50 s

Gradle resolves a selector in stages: it looks for an **exact task name/path match** first, and if that fails it tries **camelCase abbreviation** expansion. Two distinct failure modes arise: - **No match** (`tst`): `Task 'tst' not found in root project '...'`, usually with **fuzzy did-you-mean** suggestions (e.g. `test`). This stops the build immediately. - **Ambiguous abbreviation** (`comp` when `compileJava`, `compileTestJava`, `components` all exist): Gradle reports the abbreviation is ambiguous and **lists the matching candidates**, asking you to be more specific. Exact matches always win over abbreviation, so if a real task is literally named `comp`, that runs instead of being treated as an abbreviation. In multi-project builds, a name can match in several subprojects — that's selection fan-out, not an error. To investigate, use `./gradlew tasks` (or `tasks --all`) to list available tasks and `./gradlew help --task <name>` to inspect one. Robust scripts avoid these failures by using full, qualified task names.

code

bash · 3 lines
bash
./gradlew tasks --all          # discover available tasks
./gradlew help --task test     # inspect a specific task
./gradlew :app:compileTestJava # full qualified name avoids ambiguity

go deeper

for a junior

Know a wrong task name errors out and Gradle suggests close names.

for a middle

Explain the exact-then-abbreviation resolution and distinguish 'not found' from 'ambiguous'.

for a senior

Note exact-match precedence and that subproject fan-out is not an error; recommend qualified names in automation.

for a principal

Standardize discoverable task naming and CI conventions so resolution is deterministic and self-documenting (help --task, grouped tasks).

## Resolution pipeline For each selector, Gradle attempts, in order: 1. **Exact match** against a known task name (or fully qualified path). If found, done. 2. **camelCase abbreviation** expansion (per-hump prefix matching) across candidate tasks. 3. If neither yields exactly one result, it **fails**. Exact matches take precedence over abbreviation, and qualified paths (`:app:test`) bypass fan-out by naming one task. ## Failure mode 1 — task not found When no exact name and no abbreviation matches: ``` * What went wrong: Task 'tst' not found in root project 'demo'. Some candidates are: 'test'. ``` Gradle runs a similarity check to offer **did-you-mean** candidates. The build fails before executing anything. ## Failure mode 2 — ambiguous abbreviation When the abbreviation matches **more than one** task: ``` * What went wrong: Task 'comp' is ambiguous in root project 'demo'. Candidates are: 'compileJava', 'compileTestJava', 'components'. ``` You resolve it by lengthening the abbreviation (`compI` won't help — use `compileJ`/`compileT`) or typing the full name. ## Not a failure — fan-out An unqualified name matching the same task in several subprojects is **intentional** and runs them all; it is not an ambiguity error. Ambiguity errors are about a single project having multiple abbreviation candidates. ## Diagnosing ```bash ./gradlew tasks # grouped task list for the project ./gradlew tasks --all # include tasks from subprojects + non-default groups ./gradlew help --task test # description, type, options of a specific task ``` ## Avoiding it In CI and shared scripts, write the **full qualified name** so resolution never depends on the current task set. Abbreviations and fuzzy matching are conveniences for the interactive shell only.

  • If a task is literally named `comp` and `compileJava` also exists, what does `./gradlew comp` run?
    The exact-named `comp` task — exact matches take precedence over abbreviation expansion.
  • How do you list every task including those from subprojects and hidden groups?
    `./gradlew tasks --all` lists all tasks across the build, not just the default grouped subset.

saying these in an interview costs you the question

  • Treating fan-out across subprojects as an ambiguity error — it is intentional multi-selection.
  • Saying abbreviation is tried before exact matches — exact matches win.

context

resolving links…