skip to content

How do you set the organisation, module, and revision on an IvyPublication, and how do they map to other coordinate systems?

level: middleimportance: must knowfreq 28%

answer

  1. organisation = group
  2. module = name
  3. revision = version
  4. defaults from project.*
  5. <info org module rev> in ivy.xml

basics

~10 s

Inside the create<IvyPublication> block set organisation, module, and revision. They map to Maven's groupId, artifactId, and version respectively. If omitted, Gradle defaults them from project.group, project.name, and project.version.

solid answer

~40 s

An `IvyPublication` is identified by three coordinates: `organisation`, `module`, and `revision`. You assign them directly as properties in the publication block. If you do not set them, Gradle derives sensible defaults — `organisation` from `project.group`, `module` from `project.name`, and `revision` from `project.version`. These map one-to-one onto Maven's groupId/artifactId/version, and onto the `org`/`name`/`rev` attributes of the Ivy descriptor's `<info>` element. Setting them explicitly is useful when the published coordinates must differ from the project's identity — for example publishing under a different organisation or stripping a `-SNAPSHOT` style revision. The chosen revision also determines whether Gradle treats it as a status like `integration` vs `release`, which Ivy resolution can key off.

code

kotlin · 6 lines
kotlin
create<IvyPublication>("ivyJava") {
    from(components["java"])
    organisation = "com.example.platform"
    module = "billing-core"
    revision = "2.3.1"
}

go deeper

for a junior

Know that an Ivy publication has organisation/module/revision and they default from the project.

for a middle

Set them explicitly and explain the precise mapping to GAV and to ivy.xml <info> attributes.

for a senior

Discuss when published coordinates should diverge from project identity and the role of Ivy status in dynamic resolution.

for a principal

Define org-wide coordinate/namespace conventions and how revision/status policy interacts with release governance.

## The three Ivy coordinates Where Maven uses **groupId / artifactId / version (GAV)**, Ivy uses **organisation / module / revision**. On an `IvyPublication` these are exposed as plain properties: - `organisation` — the publishing org (Maven `groupId`, Ivy `org`). - `module` — the module name (Maven `artifactId`, Ivy `name`). - `revision` — the version (Maven `version`, Ivy `rev`). ## Defaults If you leave them unset, Gradle fills them in from the project: | Ivy coordinate | Default source | |----------------|----------------| | `organisation` | `project.group` | | `module` | `project.name` | | `revision` | `project.version` | So a minimal publication with only `from(components["java"])` already has coordinates, inherited from the project. You override only when the published identity must diverge from the project identity. ## How they surface in ivy.xml They become attributes of the `<info>` element in the generated `ivy.xml`: ```xml <info organisation="com.example" module="my-lib" revision="1.0.0" status="integration"/> ``` ## Status and revision Ivy carries a `status` (e.g. `integration`, `milestone`, `release`) which influences how dynamic revisions like `latest.release` resolve. Gradle infers a default status, and the revision string you publish becomes the exact version consumers request. ## Practical example ```kotlin publishing { publications { create<IvyPublication>("ivyJava") { from(components["java"]) organisation = "com.example.platform" module = "billing-core" revision = "2.3.1" } } } ``` Here the published module is `com.example.platform:billing-core:2.3.1` regardless of what `project.group`/`project.name`/`project.version` happen to be.

  • If you set none of the three coordinates, what gets published?
    Gradle defaults organisation to `project.group`, module to `project.name`, and revision to `project.version`, so the publication still has valid coordinates inherited from the project.
  • Which Ivy coordinate corresponds to Maven's artifactId?
    `module`. organisation maps to groupId and revision maps to version.

saying these in an interview costs you the question

  • Claiming the coordinates are mandatory — they default from the project.
  • Mapping module to version or revision to artifactId (the mapping is organisation→group, module→artifact, revision→version).

context

resolving links…