| [cross-project-issues-dev] OSSRH Service: Migration Status Update |
Dear All,
This message provides a status update on the OSSRH/central migration, which has been ongoing for the past four months.
All 174 Eclipse Foundation namespaces have been migrated, with the new snapshot feature enabled by default.
All Jenkins, GitHub, and GitLab secrets have been updated.
A default central publishing pipeline has been tested and documented (see migration procedure below).
The original inventory list is available here:
🔗 Migration Inventory Spreadsheet
May 30: Feedback window – projects could opt out of the June 9 migration and join the second phase on June 24. OSSRH end-of-life was confirmed for June 30, 2025.
June 9: First migration batch – all projects (except those that opted out) were moved to central.sonatype.org.
June 24: Final migration batch – all remaining projects migrated.
July 1–4: Cleanup – OSSRH secrets removed, legacy accounts deactivated, obsolete configurations deleted.
July–present: Ongoing projects support.
Progress and general requests are tracked on the main Eclipse Foundation helpdesk ticket:
Migration Helpdesk Ticket
For projects that have not yet fully adapted their build to the new Central Portal, the following steps are required:
Build adaptation:
Recommended approach: use the central-publishing-maven-plugin (v0.8.0 or later) for direct or staging publication.
Alternative for projects requiring staging: the Eclipse CBI team has developed the central-staging-plugins to handle Central’s Staging API (currently in beta):  central-staging-plugins
Central Portal introduces some constraints compared to OSSRH, particularly regarding staging:
Namespace permissions: To make staged deployments visible to project members, each user requires a Central Portal account. A helpdesk ticket must then be created, followed by a request to Sonatype support, with +1 approval from a project lead. This process does not yet scale well, as automation and inventory of permissions are still lacking. Requests should be submitted only when strictly necessary.
Permission cascading: While ownership cascades across namespaces, access does not. A user must be explicitly associated with each namespace to interact with its deployments. E.g:, an administrator user acting as the publisher for com.example would not be able to view deployments made by a CI service account publishing to the com.example.project child namespace. This visibility would only be possible if the administrator were explicitly added to the com.example.project namespace.
Artifact visibility: Staged artifacts are not publicly visible. Testing them requires authentication. A new central.test profile is being trialed in settings.xml (in JIRO) to simplify test access, though this is not yet fully deployed.
Some community concerns have been raised about the Sonatype plugin’s licensing and closed-source. These have been reported to Sonatype, no roadmap is available yet. We continue to request updates.
The central-publishing-maven-plugin does not yet fully support staging workflows, which is why the central-staging-plugins were developed as a complementary solution.
Some projects mentioned the Njord Maven plugin as an alternative, but this has not been tested or endorsed by the RelEng team.
Service disruptions: Central experienced outages (e.g., backend reindexing at Sonatype) that caused temporary downtime.
Snapshot instability: In June, the SNAPSHOT publishing backend suffered outages, and Sonatype temporarily disabled browsing access. Publishing and consumption continued to work, but the absence of UI visibility is disruptive.
Public Staging Artifacts: Staged artifacts on Central are not publicly visible until promotion. Unlike repo.eclipse.org, which made artifacts accessible for everyone, Central restricts visibility. Combined with the limitation in repo.eclipse.org that prevents overwriting the same version number, this creates difficulties for iterative testing. A long-term solution may involve using repo.eclipse.org with specific repository permissions as a transitional public staging environment and a sync mechanism with maven central.
We would like to highlight that Sonatype support has been very responsive throughout the migration. They assisted the RelEng team with many requests, even though multiple similar tickets were raised. Centralizing requests through the Eclipse Foundation Helpdesk remains the preferred approach, but direct requests and a high volume can also demonstrate the strong engagement and impact of the Eclipse community. We expect some of the pending requests to be resolved in the coming weeks and months.
Eclipse Foundation: The Community for Open Collaboration and Innovation