skip to content

When would you declare multiple entries in the `distributions {}` container, and what does each extra distribution produce?

level: seniorimportance: should knowfreq 28%

answer

  1. container allows >1 distribution
  2. non-main baseName = projectName-distName
  3. each gets own contents + task set
  4. with(copySpec) to share content
  5. assembleDist only covers main

basics

~10 s

Add more entries when one project needs several differently-packaged bundles (e.g. a server and a docs bundle). Each entry gets its own distributionBaseName, its own contents CopySpec, and its own <name>DistZip/<name>DistTar/install<Name>Dist tasks.

solid answer

~30 s

Because `distributions {}` is a `NamedDomainObjectContainer<Distribution>`, you can register additional distributions beyond `main`. You do this when a single build must emit multiple, independently-packaged artifacts — for example a `server` bundle and a `client` bundle, or a `full` vs `minimal` variant, each with different files. Each declared distribution gets its own `distributionBaseName` (defaulting to `<projectName>-<distName>`), its own `contents` `CopySpec`, and a full parallel task set (`<name>DistZip`, `<name>DistTar`, `install<Name>Dist`). They share nothing by default, so you compose their `contents` independently. This is cleaner than hand-rolling extra `Zip` tasks because you reuse the plugin's conventions, output locations (`build/distributions`, `build/install/<baseName>`), and lifecycle wiring.

code

kotlin · 7 lines
kotlin
distributions {
    create("server") {
        distributionBaseName.set("acme-server")
        contents { from("server") }
    }
}
// -> serverDistZip, serverDistTar, installServerDist

go deeper

for a junior

Know that you can have more than just main.

for a middle

Describe that each distribution gets its own base name, contents, and task set.

for a senior

Reason about when to use multiple distributions vs. variants, sharing CopySpecs, and lifecycle gaps in assembleDist.

for a principal

Govern multi-artifact packaging strategy, publishing each distribution as a resolvable variant, and naming standards across modules.

## Why more than one distribution The `main` distribution covers the common case. But some builds must ship several distinct bundles from one project. Declaring multiple distributions lets each be packaged with the plugin's conventions instead of bespoke archive tasks. Realistic motivations: - **Server vs client bundles** — same module, two deliverables with different file sets. - **Variant tiers** — a `full` distribution with extras and a `minimal` distribution with just the essentials. - **Platform splits** — e.g. a distribution carrying Linux helper scripts and one carrying Windows ones (when not handled inside a single CopySpec). ## What each extra distribution gives you Registering `create("server")` materializes: - `distributionBaseName` — defaults to `<projectName>-server` (the distribution name is appended for non-`main`). - `contents` — its own independent `CopySpec`. - Tasks `serverDistZip`, `serverDistTar`, `installServerDist`. - Outputs at `build/distributions/<baseName>[-version].zip` and `build/install/<baseName>/`. ```kotlin distributions { main { contents { from("common") } } create("server") { distributionBaseName.set("acme-server") contents { from("common") from("server-only") } } create("client") { distributionBaseName.set("acme-client") contents { from("client-only") } } } ``` ## Sharing common content Distributions do not inherit from each other. To avoid duplication, factor a shared `CopySpec` and reuse it: ```kotlin val shared = copySpec { from("common") } distributions { create("server") { contents { with(shared); from("server-only") } } create("client") { contents { with(shared); from("client-only") } } } ``` `with(spec)` merges a reusable `CopySpec` into a distribution's contents. ## Design considerations - **Naming collisions** — each distribution's task names must be unique; keep distribution names short and distinct. - **Lifecycle** — `assembleDist` targets `main`; to build all, depend on each `*DistZip` or define an aggregate task. - **Publishing** — if you publish these, attach the archive tasks as artifacts to the right configuration/component so consumers resolve the correct variant. This keeps multi-artifact packaging declarative and consistent rather than a pile of ad-hoc `Zip` definitions.

  • What is the default `distributionBaseName` for a non-`main` distribution named `server`?
    `<projectName>-server` — the distribution name is appended to the project name unless you override it.
  • How do you avoid duplicating shared files across two distributions?
    Define a reusable `CopySpec` (e.g. via `project.copySpec { ... }`) and merge it into each distribution's `contents` with `with(spec)`.
  • Does building `assembleDist` build the extra distributions?
    No, `assembleDist` aggregates only the `main` distribution. You must invoke each `*DistZip`/`*DistTar` or define your own aggregate lifecycle task.

saying these in an interview costs you the question

  • Saying non-`main` distributions inherit `main`'s contents — they are independent.
  • Assuming `assembleDist` packages every distribution.

context

resolving links…