skip to content

Explain Gradle's camelCase task-name abbreviation. Why does `./gradlew cT` often resolve to `compileTestJava`, and when does abbreviation fail?

level: middleimportance: should knowfreq 45%

answer

  1. leading letters per camel hump
  2. cT -> compileTest*, iT -> integrationTest
  3. must be unique -> else ambiguous error
  4. works in paths too (:a:cT)
  5. never in CI/scripts

basics

~20 s

Gradle lets you abbreviate a task name by typing the leading letters of each camelCase word. cT expands to a task whose words start c…T…, like compileTest. It fails if the abbreviation matches zero or more than one task.

solid answer

~50 s

Gradle supports **camelCase abbreviation** for both task names and project paths on the command line. You provide the first letter (or a prefix) of each hump in the camelCase name, and Gradle expands it. - `cT` → `compileTest` (e.g. `compileTestJava` if unambiguous), `iT` → `integrationTest`, `dependu` could match `dependencyUpdates`. - It also works inside qualified paths: `:a:cT` abbreviates the `:app` project and its `compileTest…` task. The rule is **unique prefix per hump**: each supplied segment must prefix the corresponding camelCase word. Abbreviation **fails** when the pattern matches **no task** (error: task not found) or **more than one** task (ambiguous-abbreviation error listing candidates). For example, if both `compileTestJava` and `compileTestKotlin` exist, `cT` is ambiguous and Gradle asks you to be more specific (`cTJ` / `cTK`). Abbreviation is a convenience for interactive use; **never rely on it in CI or scripts**, because adding a new task later can turn a once-unique abbreviation into an ambiguous failure.

code

bash · 3 lines
bash
./gradlew cT     # compileTest* (if unambiguous)
./gradlew cTK    # compileTestKotlin
./gradlew :a:bR  # :app:bootRun

go deeper

for a junior

Know that you can shorten task names with camelCase initials interactively.

for a middle

Explain per-hump prefix matching and the unique/zero/multiple match outcomes.

for a senior

Warn that abbreviation is build-state-dependent and unsafe in automation; prefer full qualified names.

for a principal

Codify a team rule: abbreviations for local dev only, full qualified paths everywhere reproducibility matters.

## What abbreviation is Gradle task and project names are conventionally **camelCase** (`compileTestJava`, `integrationTest`, `bootRun`). On the command line you can type an abbreviation made of the **leading characters of each camel hump**, and Gradle expands it to the full name — saving keystrokes interactively. ## How matching works Split the real name at each uppercase boundary into humps: - `compileTestJava` → `compile` | `Test` | `Java`. Your abbreviation is split the same way and each segment must be a **prefix** of the corresponding hump: - `cT` → `c`|`T` → matches `compile`+`Test…` → `compileTest*`. - `cTJ` → `c`|`T`|`J` → uniquely `compileTestJava`. - `iT` → `i`|`T` → `integrationTest`. It works for **project paths** too: `:sB:cT` abbreviates a `:services:billing`-style path plus the task. ## Success, failure, and ambiguity Three outcomes: 1. **Exactly one match** → Gradle runs it. 2. **Zero matches** → `Task 'cT' not found in root project '...'.` (with did-you-mean suggestions). 3. **Multiple matches** → an **ambiguous abbreviation** error that lists the candidates, e.g. `compileTestJava`, `compileTestKotlin`. You must lengthen the abbreviation to disambiguate. ```bash # Interactive shorthands ./gradlew cT # -> compileTest* if unique ./gradlew iT # -> integrationTest ./gradlew bR # -> bootRun # Disambiguate when several match ./gradlew cTK # -> compileTestKotlin ``` ## Why not in scripts/CI Abbreviation resolution depends on the **full set of tasks currently in the build**. A plugin upgrade or a new module can introduce a sibling task that makes a previously unique abbreviation ambiguous, breaking your pipeline non-locally. In automation, always spell the **full, qualified** task name (`:app:compileTestJava`). Abbreviation is purely an interactive ergonomic.

  • What error do you get if `cT` matches both `compileTestJava` and `compileTestKotlin`?
    An ambiguous-abbreviation error that lists both candidates and asks you to lengthen the abbreviation (e.g. `cTJ` or `cTK`).
  • Can abbreviation be applied to the project part of a path?
    Yes. Each project segment of the path can be abbreviated the same way, e.g. `:sB:cTJ` for `:services:billing:compileTestJava`.

saying these in an interview costs you the question

  • Saying abbreviation just matches any prefix substring — it is per-hump prefix matching on camelCase boundaries.
  • Recommending abbreviation in CI scripts where new tasks can silently make it ambiguous.

context

resolving links…