skip to content

Walk through what happens to a release after Gradle uploads it: the staging lifecycle on Sonatype before it appears on Maven Central.

level: seniorimportance: should knowfreq 35%

answer

  1. stage -> validate -> release -> sync
  2. close (legacy) then release
  3. validation = sigs + sources/javadoc + POM
  4. released = immutable, new version to fix
  5. index/mirror lag after release

basics

~20 s

After upload, the bundle lands in a staging area where Sonatype validates the artifacts (signatures, sources/javadoc, POM). If valid you release/publish it; it then syncs to the public Central index and mirrors within a short time.

solid answer

~50 s

Publishing is a **stage → validate → release → sync** pipeline, not a direct write. Gradle uploads the signed bundle to a staging area (an OSSRH **staging repository** in the legacy flow, or a Portal **deployment** in the new flow). Sonatype runs validation: every file has a verifying PGP signature, sources and javadoc JARs are present, and the POM has the required metadata. On the legacy Nexus you **close** the staging repo (which triggers validation) and then **release** it; on the Portal you review the validated deployment and **publish** it. After release the coordinate is written into Central and becomes resolvable from `repo1.maven.org` quickly, then propagates to downstream mirrors (e.g. the `search.maven.org` index) over a longer window. Critically, **released versions are immutable** — you can't overwrite a released `group:artifact:version`; a mistake means publishing a new version.

go deeper

for a junior

Know there's a staging/validation step and that artifacts aren't instantly on Central.

for a middle

Describe stage → validate → release and that validation checks signatures/sources/javadoc/POM.

for a senior

Explain close vs release, immutability of released versions, and the propagation/indexing lag that confuses consumers.

for a principal

Design a release process with pre-flight validation, immutability-aware versioning policy, and automated close/release in CI to remove human error.

## Staging exists to make Central trustworthy Maven Central is immutable and globally trusted, so a publish is gated: artifacts sit in a **staging** area, get **validated**, and only then are **promoted** to the public repository. Understanding this lifecycle explains why publishing 'succeeded' in Gradle but the artifact isn't yet resolvable. ## The phases 1. **Upload / stage.** Gradle's publish task pushes the bundle. In legacy OSSRH this creates a temporary **staging repository** in Nexus. In the Portal flow it creates a **deployment**. 2. **Validate.** Sonatype checks: a valid PGP signature on every artifact and the POM (and that the public key is on a keyserver), presence of `-sources.jar` and `-javadoc.jar`, and POM completeness (name/description/url/license/developers/scm). Failures mark the staging repo/deployment as failed. 3. **Close (legacy only).** On Nexus you **close** the staging repository, which finalizes it and runs the validation rules. A closed-with-errors repo must be **dropped** and re-staged. 4. **Release / publish.** You **release** the closed staging repo (legacy) or **publish** the validated deployment (Portal). This promotes the artifacts to Central. 5. **Sync & propagate.** The coordinate is written to Central's backing store and becomes resolvable from `https://repo1.maven.org/maven2/` typically within minutes; the human-facing search index and third-party mirrors update over a longer window (can be tens of minutes to a few hours). ## Immutability Once **released**, a `group:artifact:version` is **permanent and immutable** — you cannot re-upload or overwrite it. The remedy for a bad release is a **new version** (and, if necessary, asking Sonatype to mark a version as deprecated/relocated; outright deletion is exceptional). This is why pre-release validation matters so much. ## Automating the lifecycle The close/release dance is tedious by hand, so builds use plugins: the legacy `io.github.gradle-nexus.publish-plugin` adds tasks like `closeAndReleaseStagingRepository`; Portal-aware plugins perform upload-and-publish through the Publisher API. (The detailed automation tasks are the focus of a separate topic; here the point is the lifecycle they drive.) ```text upload -> [staging repo / deployment] -> validate (signatures, sources, javadoc, POM) -> close (legacy) / review (portal) -> release / publish -> repo1.maven.org (immutable) -> sync to search index + mirrors ``` ## Common interview insight If asked 'I published but `implementation("com.example:lib:1.0")` can't resolve', the answer is usually: the staging repo was closed but not released, or it's still syncing/indexing — Central resolution lags the publish, and the search UI lags resolution.

  • A teammate says the publish succeeded but the dependency still won't resolve. What are the likely causes?
    The staging repo was closed but never released, the release is still propagating to repo1.maven.org, or the search index simply hasn't caught up yet. Verify the deployment is actually published, then wait for sync.
  • Can you fix a typo in an already-released 1.0.0?
    No — released coordinates are immutable. Publish a corrected new version (e.g. 1.0.1). Deletion/relocation of a released version is exceptional and handled by Sonatype, not by re-uploading.
  • What does 'closing' a staging repository do in the legacy Nexus flow?
    It finalizes the staging repo and triggers the validation rules; a repo that closes with errors must be dropped and re-staged, while a clean close can then be released.

Staging is like a print proof: you assemble the page, the press checks it, you sign off (close+release), and only then does it go to the public print run that can't be unprinted.

saying these in an interview costs you the question

  • Saying a publish writes directly to Central with no validation step.
  • Believing you can overwrite a released version by re-running publish.
  • Confusing 'closed' with 'released' — closing only validates; releasing promotes.

context

resolving links…