skip to content

How does the distribution plugin name the tasks it generates per distribution, and how does that differ between `main` and a non-`main` distribution?

level: middleimportance: must knowfreq 45%

answer

  1. main name is elided in task names
  2. custom -> customDistZip / installCustomDist
  3. Zip + Tar + Sync task types
  4. assembleDist aggregates main zip+tar
  5. container all{} registers tasks lazily

basics

~10 s

For main the tasks are distZip, distTar, installDist, assembleDist. For any other distribution named <x> Gradle capitalizes and infixes the name: <x>DistZip, <x>DistTar, install<X>Dist. The main name is elided.

solid answer

~30 s

The plugin registers tasks lazily for every element in `distributions {}`. The naming rule treats `main` as the implicit default, so its tasks drop the name: `distZip`, `distTar`, `installDist`, plus the `assembleDist` aggregate. For a distribution declared as e.g. `custom`, the same tasks become `customDistZip`, `customDistTar`, and `installCustomDist` (the name is title-cased and spliced into the task name). Each archive task is a `Zip`/`Tar`, and each install task is a `Sync` writing to `build/install/<baseName>`. Because registration is lazy (`tasks.register`-style via the container), adding a distribution at configuration time automatically materializes its task set without you wiring anything manually.

code

bash · 3 lines
bash
./gradlew tasks --group distribution
# main:   distZip, distTar, installDist, assembleDist
# custom: customDistZip, customDistTar, installCustomDist

go deeper

for a junior

Recall that main produces distZip/distTar/installDist.

for a middle

State the infix convention for non-main distributions and the underlying Zip/Tar/Sync task types.

for a senior

Explain lazy registration through the NamedDomainObjectContainer and how the tasks join the assemble lifecycle.

for a principal

Discuss governing multiple distributions in a multi-artifact release and avoiding task-name collisions across plugins.

## Why naming matters The distribution plugin turns each element of the `distributions {}` container into a parallel family of tasks. Understanding the naming convention lets you invoke the right task from the command line and wire dependencies correctly. ## The convention Gradle uses the distribution's **name** as an infix, except `main` which is treated as the unnamed default: | Distribution | Zip task | Tar task | Install task | |---|---|---|---| | `main` | `distZip` | `distTar` | `installDist` | | `custom` | `customDistZip` | `customDistTar` | `installCustomDist` | | `docs` | `docsDistZip` | `docsDistTar` | `installDocsDist` | Plus a lifecycle aggregate `assembleDist` that depends on the zip + tar tasks of the `main` distribution. `assemble` (from the base plugin) transitively builds the archives because the distribution archive tasks are added to the `archives`/`assemble` graph. ## Task types - The `*DistZip` task is a `Zip` task. - The `*DistTar` task is a `Tar` task. - The `install*Dist` task is a `Sync` task — it mirrors `contents` into `build/install/<baseName>`, deleting stale files. ## Lazy registration via the container ```kotlin distributions { create("custom") { distributionBaseName.set("my-tool") contents { from("extra") } } } // materializes: customDistZip, customDistTar, installCustomDist ``` Because `distributions` is a `NamedDomainObjectContainer`, the plugin uses container callbacks (`all { ... }`) to register tasks for each element as it is created — so you never hand-write the task definitions. This is the same lazy-configuration mechanism (`Provider`/`Property`, deferred registration) used across modern Gradle. ## Practical CLI use `./gradlew installDist` exploded-installs `main`; `./gradlew installCustomDist` does the `custom` one. Tab-completion and `./gradlew tasks --group distribution` reveal the generated set.

  • What underlying task type is `installDist`?
    A `Sync` task — it copies the distribution `contents` into `build/install/<baseName>` and removes files no longer present, keeping the install directory clean.
  • Does `assembleDist` build every distribution?
    By default it aggregates the `main` distribution's zip and tar. Non-`main` distribution archive tasks are wired into `assemble`, but `assembleDist` specifically targets `main`.

saying these in an interview costs you the question

  • Saying a distribution named `custom` produces `distCustomZip` — the order is `customDistZip` (name first for zip/tar, but `install<Name>Dist` for install).
  • Assuming you must manually register the per-distribution tasks.

context

resolving links…