skip to content

What exactly does the `clean` task delete, and how do the `base { }` extension and `archives` configuration relate to it?

level: middleimportance: should knowfreq 40%

answer

  1. clean deletes layout.buildDirectory only
  2. not src/, not ~/.gradle
  3. clean<Task> per-output rule
  4. base{} = archivesName + libs/dists dirs
  5. archives feeds assemble

basics

~20 s

clean is a Delete task that removes the project's build directory (layout.buildDirectory, default build/). The base { } extension sets archive naming and output dirs; the archives configuration collects artifacts that assemble builds — both feed outputs under build/.

solid answer

~40 s

`clean` is a simple `Delete` task created by `lifecycle-base` that deletes `layout.buildDirectory` — by default `build/`, where all generated outputs live. It does not delete sources, caches outside the project (like `~/.gradle`), or `src/`. `lifecycle-base` also provides a rule to create `clean<TaskName>` tasks that delete a single task's outputs. The `base` plugin adds the `base { }` extension (`archivesName`, `libsDirectory`, `distsDirectory`) controlling *where* archive outputs go (under `build/libs`, `build/distributions`) and their base file names — so what `clean` removes is partly shaped by these settings. The `archives` configuration is the bucket of produced artifacts that `assemble` is wired to build. Together: `base { }` decides naming/location, `archives` collects the artifacts, `assemble` produces them into `build/`, and `clean` wipes `build/` to reset state.

code

kotlin · 6 lines
kotlin
// What clean removes, conceptually:
tasks.register<Delete>("clean") {
    delete(layout.buildDirectory)   // default: build/
}

base { archivesName = "my-app" }    // -> build/libs/my-app-<version>.jar (also cleaned)

go deeper

for a junior

Knowing clean deletes the build/ directory is the core fact.

for a middle

Be precise about scope (only buildDirectory, not caches/src) and mention base{} naming and the archives configuration.

for a senior

Explain the clean<Task> rule, multi-project clean semantics, and how base{} locations determine what clean sweeps.

for a principal

Discuss reproducible clean build as a CI hygiene contract and where teams misuse clean to mask caching/incremental-build issues.

## `clean` — precise scope `clean` is registered by `lifecycle-base` as a `Delete` task: ```kotlin tasks.register<Delete>("clean") { delete(layout.buildDirectory) } ``` It deletes **only** `layout.buildDirectory` (default `build/`). It does **not** touch: - `src/` or any source/resources, - the Gradle user home / dependency cache (`~/.gradle`), - the build cache or configuration cache, - sibling projects' build dirs (each project has its own `clean`). In a multi-project build, the root `clean` does not recursively clean subprojects unless wired to; each subproject's `clean` handles its own `build/`. ### Per-output clean rules `lifecycle-base` adds a rule so `clean<TaskName>` (e.g. `cleanJar`) deletes just that task's declared outputs — handy when you want to invalidate one task without wiping the whole build dir. ## `base { }` — naming and locations The `base` plugin's extension (`BasePluginExtension`) controls archive conventions: ```kotlin base { archivesName = "my-app" // file base name libsDirectory.set(layout.buildDirectory.dir("libs")) distsDirectory.set(layout.buildDirectory.dir("distributions")) } ``` So a JAR becomes `build/libs/my-app-<version>.jar`. Because these directories live under `build/`, they're swept by `clean`. ## `archives` configuration `base` creates the `archives` configuration: a bucket of the project's published archive artifacts. Anything added to it (`artifacts { archives(jarTask) }`) is wired so `assemble` builds it. It's the conventional way older plugins exposed their outputs for assembly and publishing. ## How they fit together 1. `base { }` decides *names* and *output directories*. 2. Producing tasks (jar, zip) write there and are added to `archives`. 3. `assemble` depends on those producers, so `gradle assemble`/`build` creates them. 4. `clean` deletes `build/`, removing everything produced in steps 1-3. This closed loop is why a `clean build` reliably reproduces all outputs from scratch.

  • Does `clean` clear the dependency cache or build cache?
    No. It only deletes the project's `build/` directory. The dependency cache (~/.gradle) and the build cache are separate and untouched.
  • How would you delete just one task's outputs without wiping the whole build dir?
    Run the rule-generated `clean<TaskName>` task, e.g. `gradle cleanJar`, which deletes only that task's declared outputs.

saying these in an interview costs you the question

  • Claiming `clean` clears the Gradle dependency or build cache.
  • Saying `clean` recursively cleans all subprojects automatically.
  • Confusing the `archives` configuration with the `build/` directory.

context

resolving links…