skip to content

Why might you register an IvyPublication lazily and declare several publications, and how does that interact with the descriptor?

level: seniorimportance: should knowfreq 14%

answer

  1. publications = NamedDomainObjectContainer
  2. register<> = lazy vs create<> eager
  3. one descriptor + tasks per publication
  4. descriptor scoped per publication
  5. extra module name = API commitment

basics

~10 s

You can register more than one IvyPublication (e.g. main + a variant) in the publications container; each gets its own coordinates and descriptor. Lazy registration avoids configuring publications that no task needs.

solid answer

~40 s

The `publications {}` container is a `NamedDomainObjectContainer`, so you can register multiple `IvyPublication` entries — for instance a primary library publication and a separate one for an alternate component or extra artifacts. Each publication has independent `organisation`/`module`/`revision` and its own `descriptor { }`, and the plugin generates a distinct `generateDescriptorFileFor<Name>Publication` and `publish<Name>...` task per publication. Prefer the lazy/configuration-avoidance idioms: in Kotlin `register<IvyPublication>("name")` (vs `create`) defers configuration until the publication is actually needed, which keeps configuration time down. Because each publication writes its own `ivy.xml`, descriptor customization is per-publication — author/description/license you set on one do not leak to another. This is the standard pattern when you must publish the same project under multiple module names or with different metadata.

code

kotlin · 12 lines
kotlin
publishing {
    publications {
        register<IvyPublication>("main") {
            from(components["java"])
            module = "billing-core"
        }
        register<IvyPublication>("legacy") {
            from(components["java"])
            module = "billing"
        }
    }
}

go deeper

for a junior

Know that more than one publication can be declared, each with its own coordinates.

for a middle

Register multiple publications correctly and know each has independent tasks and descriptor.

for a senior

Justify lazy register, explain per-publication descriptor isolation, and the task multiplication trade-off.

for a principal

Weigh alias/module-name proliferation as a versioned API contract and codify a one-canonical-publication policy with exceptions.

## Multiple publications `publishing { publications { } }` is a `NamedDomainObjectContainer<Publication>`. Nothing limits you to one `IvyPublication` — you may register several, each a fully independent publication with its own coordinates, artifacts, and descriptor. Typical reasons: - Publish the same build under two module names (e.g. a legacy name and a new name). - Publish a main component plus a thin metadata-only or platform-style publication. - Emit different descriptor metadata (different license/author) for internal vs external repositories. ## Per-publication tasks For each publication the plugin lazily registers: - `generateDescriptorFileFor<Name>Publication` - `publish<Name>PublicationTo<Repo>Repository` So two publications double the task set, and the aggregate `publish` covers all of them. ## Lazy registration (configuration avoidance) Gradle's configuration-avoidance API matters here. Prefer `register<IvyPublication>("name") { ... }` over `create<IvyPublication>("name") { ... }`: `register` returns a provider and only realizes (configures) the publication when something needs it, whereas `create` configures eagerly. With several publications the savings compound, and it keeps the configuration phase fast. ```kotlin publishing { publications { register<IvyPublication>("main") { from(components["java"]) module = "billing-core" descriptor { license { name = "Apache-2.0" } } } register<IvyPublication>("legacy") { from(components["java"]) module = "billing" // old module name descriptor { description { text = "Deprecated alias" } } } } } ``` ## Descriptor isolation Because each `IvyPublication` owns its `descriptor`, customization is scoped to that publication. Authors, descriptions, and licenses set on `main` do not appear in `legacy`'s `ivy.xml`. This isolation is what makes multi-publication setups safe — you reason about each descriptor independently. ## Trade-offs Multiple publications multiply tasks, descriptors, and the surface area consumers can depend on. Treat extra module names as a long-term API commitment, and prefer a single canonical publication unless a real consumer requires the alias.

  • What is the difference between create<IvyPublication> and register<IvyPublication>?
    `create` configures the publication eagerly during configuration; `register` is lazy (configuration avoidance) and only realizes it when needed, which is preferable for build performance.
  • If you set a license on one publication, does it apply to the others?
    No. Each IvyPublication owns its own descriptor, so descriptor metadata is isolated per publication.
  • What is a downside of publishing under two module names?
    Each name is a long-lived contract consumers may depend on, doubling maintenance surface; aliases should be added only when a real consumer requires them.

saying these in an interview costs you the question

  • Claiming only one IvyPublication can exist per project.
  • Assuming descriptor metadata is shared across publications.
  • Preferring eager `create` when `register` would avoid unnecessary configuration.

context

resolving links…