skip to content

Contrast the Central Portal (central-publishing-maven-plugin) with the legacy OSSRH/Nexus staging flow. How does a deploy-to-release work in each?

level: seniorimportance: should knowfreq 35%

answer

  1. OSSRH = Nexus staging: deploy→close→release
  2. Portal = upload deployment bundle, validate, publish
  3. central-publishing-maven-plugin + publishingServerId
  4. autoReleaseAfterClose vs autoPublish
  5. user tokens in settings.xml, OSSRH sunsetting

basics

~20 s

Legacy OSSRH used a Nexus staging repository: you deploy, a staging repo is created, you close it (runs validations), then release it. The new Central Portal uses central-publishing-maven-plugin to upload a deployment bundle that's validated and published; OSSRH is being retired.

solid answer

~50 s

Both flows enforce the same rules (signed artifacts, metadata, verified namespace) but differ mechanically. **Legacy OSSRH (Sonatype Nexus):** configure `nexus-staging-maven-plugin`, `mvn deploy` pushes to a per-deploy **staging repository**; you then **close** it (Nexus runs validation rules), and **release** it to promote to Central (or `drop` it on failure). It supports `autoReleaseAfterClose`. **Central Portal (`central.sonatype.com`):** the new system. You add the **central-publishing-maven-plugin** with a `publishingServerId` and credentials (a user token from the portal in `settings.xml`). `mvn deploy` bundles and uploads a **deployment** that is validated; with `<autoPublish>true` it releases automatically, otherwise you approve it in the portal UI. Sonatype is migrating all projects to the Portal and OSSRH staging is being sunset, so new projects should use the Central Portal plugin. Credentials in both cases are user tokens, not your raw password, stored in `~/.m2/settings.xml` under a `<server>`.

code

xml · 10 lines
xml
<plugin>
  <groupId>org.sonatype.central</groupId>
  <artifactId>central-publishing-maven-plugin</artifactId>
  <version>0.7.0</version>
  <extensions>true</extensions>
  <configuration>
    <publishingServerId>central</publishingServerId>
    <autoPublish>true</autoPublish>
  </configuration>
</plugin>

go deeper

for a junior

Aware there is a portal/UI step after deploy to actually release.

for a middle

Knows the central-publishing-maven-plugin and basic settings.xml token setup.

for a senior

Can contrast Nexus close/release staging with the Portal deployment-bundle flow and choose appropriately.

for a principal

Plans org migration off OSSRH, standardizes credentials/token rotation and CI publishing.

## Same goal, two mechanisms Both publish to the same Maven Central, with identical requirements (GPG `.asc`, sources/javadoc, required POM metadata, verified groupId). They differ in *how you get from `mvn deploy` to a public release*. ## Legacy OSSRH (Nexus staging) OSSRH = OSS Repository Hosting, backed by Sonatype **Nexus**. 1. Add **nexus-staging-maven-plugin** and a `<distributionManagement>` pointing at the OSSRH URL. 2. `mvn clean deploy` → Nexus opens a **staging repository** (a temporary, private area). 3. **Close** the staging repo → Nexus runs validation (signatures, metadata, coordinates). 4. **Release** it → artifacts are promoted to Central and sync out. On failure you **drop** the staging repo and retry. ```xml <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <version>1.6.13</version> <extensions>true</extensions> <configuration> <serverId>ossrh</serverId> <nexusUrl>https://s01.oss.sonatype.org/</nexusUrl> <autoReleaseAfterClose>true</autoReleaseAfterClose> </configuration> </plugin> ``` ## Central Portal (current) The modern system at **central.sonatype.com**, using the **central-publishing-maven-plugin**. 1. Generate a **user token** in the portal; put it in `settings.xml` as a `<server>`. 2. Add the plugin with `<publishingServerId>` matching that server id. 3. `mvn clean deploy` → it assembles a **deployment bundle** and uploads it; Central validates. 4. With `<autoPublish>true>` it publishes automatically; otherwise you click **Publish** in the portal (or it stays as a validated, droppable deployment). ```xml <plugin> <groupId>org.sonatype.central</groupId> <artifactId>central-publishing-maven-plugin</artifactId> <version>0.7.0</version> <extensions>true</extensions> <configuration> <publishingServerId>central</publishingServerId> <autoPublish>true</autoPublish> </configuration> </plugin> ``` ```xml <!-- ~/.m2/settings.xml --> <server> <id>central</id> <username>TOKEN_USERNAME</username> <password>TOKEN_PASSWORD</password> </server> ``` ## Which to use Sonatype is **migrating everyone to the Portal**; OSSRH staging is being retired. **New projects: use the Central Portal plugin.** Existing OSSRH projects are being transitioned. Both still require signing and metadata; the difference is the staging-and-promote ceremony (Nexus close/release) vs. a single validated deployment bundle. ## Credentials note Never store your raw account password — both flows use **user tokens** generated in the respective UI, referenced by `<server><id>` in `settings.xml`.

  • In the OSSRH flow, what do 'close' and 'release' do?
    Close finalizes the staging repository and runs validation rules; release promotes the validated staging repo to Maven Central. A failed close lets you drop and retry.
  • Where are publishing credentials stored and what form do they take?
    In ~/.m2/settings.xml under a <server> entry matching the plugin's server id; they are user tokens (username/password pair) generated in the portal, not your raw login password.
  • Which approach should a new project pick today?
    The Central Portal with central-publishing-maven-plugin, since OSSRH/Nexus staging is being retired by Sonatype.

saying these in an interview costs you the question

  • Confusing the staging repo with the snapshot repo
  • Storing the raw account password instead of a user token
  • Assuming OSSRH is still the recommended path for new projects

context

resolving links…