[publishing] Add support for the new maven central publisher API

[martinbonnin]

Expected Behavior

Sonatype is changing how artifacts are uploaded with new accounts. See https://central.sonatype.org/register/central-portal/ and https://central.sonatype.org/publish/publish-portal-api/

The new API uploads a single zip file containing a full publication in one go and as a result the current method doesn't work anymore. Would be nice to have built-in support for the new API in the maven-publish plugin.

Current Behavior (optional)

No response

Context

vanniktech/gradle-maven-publish-plugin#722
KotlinLang slack discussion

[ljacomet]

This is something that we are discussing internally and probably will discuss with Sonatype.

An official plugin from Sonatype would be the best option since they own the protocol which is no longer based on Maven deploy.

If an official Gradle plugin adds that support, it would also make sense to have it outside of the Gradle core plugins, since Sonatype could change their protocol anytime.

[martinbonnin]

Not sure if this is still on the table for Sonatype but keeping a similar API would be quite handy:

• no need to change every library using Gradle/Maven out there
• could parallelize the uploads and/or upload from different machines (for KMP for an example)

I get that the current implicit staging repos and the split repos are an issue but sounds like this could be fixed transparently for end users by wrapping the file uploads in creation/close API calls?

While I understand the rationale for a new plugin, adding yet another publishing plugin is going to add more complexity to an already complex landscape.

Anyways, I understand this is ultimately not in Gradle hands but these were my 2 cents! Thanks for reading!

[asarkar]

@ljacomet

An official plugin from Sonatype would be the best option since they own the protocol

Sonatype has a page listing dozens of Gradle plugins that use the Central Publishing Portal. There's no indication that they ever intend to create a plugin of their own. As for the protocol, if all these third-party plugins could implement it, why can't Gradle?

[hfhbd]

@asarkar

There's no indication that they ever intend to create a plugin of their own.

It is: so we wanted to communicate that Gradle support is on our roadmap.

[asarkar]

so we wanted to communicate that Gradle support is on our roadmap

I saw that. Actual roadmaps have milestones and release dates, they have published none. That statement sounds nothing more than an apology to the backlash for breaking the now legacy API. The Central API is now almost a year old.

[osiegmar]

Just received a reminder email from Sonatype that states:

As you may have heard, OSSRH is reaching end of life on June 30, 2025. OSSRH users need to migrate their namespaces to the Central Portal as soon as possible.

Instructions for self migration are located here: https://central.sonatype.org/faq/what-is-different-between-central-portal-and-legacy-ossrh/#self-service-migration

To make the transition smoother we will be automatically migrating publishers that have not used oss.sonatype.org or s01.sonatype.org to publish artifacts in some time starting with the oldest and working our way forward. To avoid disruption to your publishing processes we strongly encourage migrating before the June 30, 2025 deadline.

Any update on this issue or advice on how to move forward?