microsoft
End-of-Life Sunset Date for OSSRH - June 30th
https://central.sonatype.org/news/20250326_ossrh_sunset/
It is my understanding that this repo is using OSSRH behind the curtains to publish releases.
I think that this is something "owned" by some Microsoft department, but opening an issue for tracking purposes.
Hi @andreaTP Thanks for pointing this out.
First off, here is a migration documentation that's super helpful for anybody reading this issue
I just checked with the new central portal, and we're NOT able to migrate automatically.
For clarity OSSRH is NOT owned by anybody at Microsoft. But some cross-company coordination happens.
Microsoft does have a centralized ESRP release platform that supports java packages, but it'd require migrating everything back to Azure DevOps. At the time this was deployed, we were granted a perpetual exception until that platform becomes available for GitHub actions.
We're currently using mavin publish to push the binaries to OSSRH and the nexus publish plugin to automatically perform the steps that used to be manual.
From a quick look at the nexus publish repo it seems that one avenue could be to:
- drop the maven publish plugin
- centralize the configuration + urls on nexus publish
- do we need to change anything to close and release automatically? from reading the docs it doesn't seem so
Another avenue would be to use the built-in maven publish plugin for the upload, and simply update the url
In both cases we also need to:
- request the migration of the namespace
- update the workflow to use a token from the portal instead of a password.
Does that make sense? do you have additional input to provide? is this something you've already done for std uri template?
- drop the maven publish plugin
Correct, it should be replaced by the new one.
- centralize the configuration + urls on nexus publish
Possibly, that's some kind of an optimization.
- do we need to change anything to close and release automatically? from reading the docs it doesn't seem so
Everything can be configured to be automatic, for example.
In both cases we also need to:
yes and yes.
Everything makes sense, I have not migrated yet std-uritemplate (contacted Support but on-going) but the migration went "well" in other repositories, my experience, so far, has been only with Maven builds.
Thank you for the additional information.
I think we'll wait for you to report the experience in std uritemplate here (and potentially link the PR with changes) before we proceed. The learnings will be precious!
@andreaTP what was your experience migrating over? anything you'd like to share here?
For context, the migration work was done for std uri template. But that lib is using maven and not gradle, so we'll have to figure the recipe out from the ground up here.
https://github.com/std-uritemplate/std-uritemplate/pull/329
Sorry I missed the ping!
I finished to migrate all my repos to the new coordinates and everything worked out, I only got one timeout so far. This blog is well done and comprehensive for Maven: https://maxrohde.com/2025/05/08/migrating-maven-namespace-to-central-portal/
For Gradle I have no experience but this looks like a good link to start with: https://slack-chats.kotlinlang.org/t/27557449/has-anyone-here-been-through-the-migration-process-for-their
As an update: Microsoft has a team called "central package management" which centralizes packages publishing for feeds that are NOT federated with our identity systems. Maven central being one of those.
They are already handling the migration to the new publishing APIs as long as we're using their system. (which we were not) I've started the migration, which also requires migrating to azure devops, over at #1951 We're facing some issues with their systems and have an ongoing incident opened with them. Hopefully, they'll resolve it before the cut off date.
https://portal.microsofticm.com/imp/v5/incidents/details/645244801/summary