skip to content

What problem does the io.github.gradle-nexus.publish-plugin solve, and what would you have to do manually without it?

level: juniorimportance: must knowfreq 55%

answer

  1. open → upload → close → release
  2. wraps Nexus staging REST API
  3. applied at root project
  4. nexusPublishing { sonatype { } }
  5. no more Nexus web UI clicks

basics

~10 s

It automates Sonatype staging: it creates a staging repository, publishes your artifacts into it, then closes and releases it from the build — so you don't click through the Nexus/Central Portal UI by hand.

solid answer

~40 s

Publishing a release to Maven Central via Sonatype OSSRH (or the newer Central Portal) is a multi-step staging dance: open a staging repository, upload all artifacts (jars, sources, javadoc, POM, signatures) into it, **close** it (which triggers validation rules), then **release** it (which promotes to Central). Done by hand that means logging into the Nexus web UI and clicking buttons. The `io.github.gradle-nexus.publish-plugin` wraps the Nexus staging REST API so all of that happens from Gradle tasks. You configure `nexusPublishing { repositories { sonatype { } } }`, point your `maven-publish` publication at the generated staging URL, and the plugin contributes tasks like `publishToSonatype` and `closeAndReleaseSonatypeStagingRepository`. The payoff is a fully scripted, repeatable release you can run from CI.

code

kotlin · 11 lines
kotlin
plugins {
    `maven-publish`
    id("io.github.gradle-nexus.publish-plugin") version "2.0.0"
}

nexusPublishing {
    repositories {
        sonatype()  // pre-wired OSSRH endpoints; reads credentials from properties/env
    }
}
// Contributed tasks: publishToSonatype, closeAndReleaseSonatypeStagingRepository

go deeper

for a junior

Know the four-step lifecycle (open/upload/close/release) and that the plugin replaces the Nexus web UI clicks.

for a middle

Explain it wraps the staging REST API, is applied at the root, and name the key tasks (publishToSonatype, closeAndReleaseSonatypeStagingRepository).

for a senior

Tie it to Central's immutability and why close runs validation; explain the maven-publish integration that injects the staging URL.

for a principal

Frame it as scripting an irreversible promotion gate; discuss governance of who may release and the migration from OSSRH to the Central Portal.

## Why staging exists Maven Central is immutable: once a version is published it can never be changed or deleted. To protect that, Sonatype puts a **staging** step in front of Central. A staging repository is a temporary, private repo that holds your candidate release until you explicitly promote it. The lifecycle is: 1. **Open** a staging repository (you get a server-assigned id like `comexample-1023`). 2. **Upload** every artifact for the release into it: the main jar, `-sources.jar`, `-javadoc.jar`, the `.pom`, and a `.asc` PGP signature for each. 3. **Close** the repository — Sonatype now runs validation rules (POM completeness, valid signatures, javadoc/sources present, group ownership). Close fails if any rule is violated. 4. **Release** the repository — the contents are promoted to Central and begin syncing. ## What the plugin automates The `io.github.gradle-nexus.publish-plugin` (current line is 2.x) talks to the Nexus **staging REST API** so steps 1, 3, and 4 become Gradle tasks, and it wires step 2 by injecting the staging-repo URL into your `maven-publish` `MavenPublication`. You apply it at the **root** of the build (it is a settings/root-project-level plugin because it coordinates across modules) and configure: ```kotlin nexusPublishing { repositories { sonatype { /* credentials + endpoints */ } } } ``` The `sonatype { }` shortcut pre-fills the OSSRH endpoints. The plugin then registers an extension target like `initializeSonatypeStagingRepository`, `publishToSonatype`, `closeSonatypeStagingRepository`, `releaseSonatypeStagingRepository`, and the convenience aggregate `closeAndReleaseSonatypeStagingRepository`. ## The manual alternative Without it you'd run `publish` to push to the OSSRH `staging/deploy` URL, then open the Nexus Repository Manager web UI, find your staging repo among possibly several, select it, click **Close**, wait for validation, then click **Release**. That is error-prone, not scriptable, and impossible to run unattended in CI. ## first principles takeaway The plugin's whole job is to turn a click-through web workflow into idempotent, CI-runnable Gradle tasks by calling the staging REST API on your behalf.

  • Why is a Maven Central release immutable, and how does that influence staging?
    Central never lets you overwrite or delete a published version (reproducibility/security). Staging gives you a last validation-and-review gate before that irreversible promotion.
  • At which project level do you apply this plugin and why?
    The root project. It coordinates a single staging repository shared across all modules of a multi-module build, so it needs a build-wide vantage point.

Staging is like a shipping container you load privately, seal (close), then hand to the carrier (release) — the plugin is a robot that does the loading, sealing and handoff instead of you doing it by hand at the dock.

saying these in an interview costs you the question

  • Saying the plugin uploads directly to Central — it uploads to a staging repo, then promotes.
  • Thinking you can re-publish the same version to fix a mistake — Central is immutable.

context

resolving links…