Migration to Sonatype Central Portal – What You Need to Do!

[clementnero]

Dear Community,

Warning

All Camunda namespaces have been migrated (io.camunda, io.zeebe, and org.camunda). Please ensure you complete the actions below if you haven't already.

🚨 Sonatype is retiring the legacy OSSRH service and moving all artifact publishing to their new Central Portal. This affects all Camunda namespaces (io.camunda, io.zeebe, and org.camunda).

📢 Before you start:
Please review the Migration details and FAQ carefully. It covers everything you need to know for a smooth transition.

👉 Next: To ensure your project’s publishing continues seamlessly, please follow these recommended steps now, you don’t need to wait for the namespace migration to be effective!

What You Should Do Today:

1. Upgrade your parent POM to version 2.0.0 or higher to get the new central-sonatype-publish Maven profile
2. Update your deployment workflow to use @v2 of camunda-community-hub/community-action-maven-release:
   • Remove any central-release-profile input to use the new default
   • Add new credentials for the Central Portal (see Migration details / FAQ)
   • Keep deprecated OSSRH parameters temporarily for backward compatibility (see Migration details / FAQ).

🔁 The GitHub Action (@v2) will handle switching between OSSRH and Central Portal per namespace.

📍 If you consume SNAPSHOT artifacts, remember to update your repository URL as per Sonatype’s new guidelines:
https://central.sonatype.com/repository/maven-snapshots/

📌 Example PR with required changes: camunda-community-hub/community-hub-extension-example#30

📅 Namespace Migration Schedule

Namespace	Planned Migration Date
io.zeebe	June 11, 2025 ✅
io.camunda	June 23, 2025 ✅
org.camunda	June 23, 2025 ✅

Thank you for your attention and cooperation!

---

🔗 Migration details are available here:
Migration to Sonatype Central Portal — How To? (FAQ)

[clementnero]

We noticed that validation rules in Central Portal seem to be a bit stricter compared to the legacy OSSRH.

• each module must declare a <name>
• jar packaging modules must deploy a *-javadoc.jar, even for bundle modules (no source code, just assembling dependencies)

maven-jar-plugin can be used to generate (empty) javadoc jar if needed:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <executions>
    <execution>
      <id>javadoc-jar</id>
      <phase>package</phase>
      <goals>
        <goal>jar</goal>
      </goals>
      <configuration>
        <classifier>javadoc</classifier>
        <classesDirectory>${basedir}/main/resources/javadoc</classesDirectory>
      </configuration>
    </execution>
  </executions>
</plugin>