Migrate from OSSRH to Central

[cpovirk]

See https://central.sonatype.org/pages/ossrh-eol/ and https://central.sonatype.org/publish/publish-portal-maven/.

I had told @eamonnmcmanus that I would make an attempt at this, but I am emerging defeated... :)

The source-code changes for most of our own migrations have looked like google/truth#1544. I started working on a similar change to GSON, removing <distributionManagement>, removing maven-deploy-plugin from dependencyManagement, and adding central-publishing-maven-plugin to dependencyManagement with <skipPublishing>${gson.isInternalModule}</skipPublishing> inside the configuration section. I also tried listing central-publishing-maven-plugin inside the release profile.

On top of that, we had to create a new user token, following the instructions at https://central.sonatype.org/publish/generate-portal-token/, and plug it into ~/.m2/settings.xml. (I've been using <id>central</id>, but I'm not sure if that exact name is significant.)

Anyway, I was working through the quite detailed instructions at https://github.com/google/gson/blob/main/ReleaseProcess.md (even knowing that I wouldn't ultimately have the permissions to deploy), and I got the impression that maven-release-plugin (which I hadn't used before) is running maven-deploy-plugin whether we want it to or not.

It is probably possible to continue using maven-deploy-plugin (instead of migrating to central-publishing-maven-plugin) by switching to the legacy shim API documented at https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/. However, I and others have had trouble with missing files in our resulting deployments. (Supposedly that is an issue only if you upload different files from different IPs, but that seems highly unlikely in the cases I'm aware of. I think I may at least have heard that there were some potential fixes to remaining issues.) But as a more general point, it's a legacy shim.

The right thing to do is probably to either migrate off maven-release-plugin (at least for the actual deployment) or to find a way to force it to use central-publishing-maven-plugin instead of maven-deploy-plugin (if possible).

[cpovirk]

On top of that, we had to create a new user token, following the instructions at https://central.sonatype.org/publish/generate-portal-token/, and plug it into ~/.m2/settings.xml. (I've been using <id>central</id>, but I'm not sure if that exact name is significant.)

Oh, it needs to match the publishingServerId in the pom.xml. The default is central, so that's what I'd put in ~/.m2/settings.xml. Incidentally, I've also been meaning to rip out the redundant values that we've been setting in pom.xml in all our projects, so: google/truth#1575

[Marcono1234]

and I got the impression that maven-release-plugin (which I hadn't used before) is running maven-deploy-plugin whether we want it to or not

How entangled are maven-release-plugin and maven-deploy-plugin? In case maven-release-plugin just runs mvn deploy (which the documentation suggests), then would it be possible to set <skip>true</skip> for maven-deploy-plugin (assuming this is necessary because Maven configures the plugin by default, see documentation), and additionally configure the central-publishing-maven-plugin?

https://vaadin.com/blog/how-to-publish-java-libraries-to-maven-central-using-your-github-account also suggests it should be possible to combine maven-release-plugin and central-publishing-maven-plugin, but they don't explicitly disable maven-deploy-plugin. Maybe they just forgot it in their blog post (edit: maven-deploy-plugin seems to be disabled implicitly, see comment below)?

Not sure if this works though; I am not familiar with publishing to Maven Central.

[Marcono1234]

It seems central-publishing-maven-plugin can on its own disable the maven-deploy-plugin execution, see source code (unofficial mirror); this probably requires the <extensions>true</extensions> though, as shown in the central-publishing-maven-plugin documentation. But it might not apply if you specify explicit executions for central-publishing-maven-plugin, see this comment and source code.

So to be on the safe side, I guess it does not hurt to explicitly set <skip>true</skip> for the maven-deploy-plugin.

[cpovirk]

I have been unclear on how entangled the two plugins are. Part of my confusion is that, when we run deploy for various Google projects, we see only the new central-publishing-maven-plugin run, not maven-deploy-plugin. I'm not sure why I wasn't able to replicate that with Gson. Your most recent comment gets into things much more deeply than I did.

<skip>true</skip> does sound like a good approach to me, one that I wish I had have thought to try.

[cpovirk]

I've pushed the tiny bit of changes that I'd made plus the <skip>true</skip> suggestion of @Marcono1234: 3742a7a.

skip does get things further: The failure that I'm now seeing is this:

[INFO] [ERROR] Failed to execute goal org.sonatype.central:central-publishing-maven-plugin:0.8.0:publish (injected-central-publishing) on project test-graal-native-image: The packaging for this project did not assign a file to the build artifact -> [Help 1]

That might be avoidable with an edit to test-graal-native-image/pom.xml to make it skip central-publishing-maven-plugin for that module.

---

Here are some notes about my non-standard attempts to test things:

# from branch `central`
# (`release:prepare` will push stuff, so you don't want it to be pushed to `main` during testing.)
# (That wouldn't be an issue if I were following https://github.com/google/gson/blob/main/ReleaseProcess.md fully, sorry.)

$ git push --delete upstream central
# or
$ git push --delete origin central
# or whatever
# (so that the push performed by `release:prepare` can succeed)

$ git tag -d gson-parent-2.13.2

$ git push --delete upstream gson-parent-2.13.2
# or
$ git push --delete origin gson-parent-2.13.2
# or whatever

$ git reset --hard whatever-commit-i-had-before-the-release-prep

$ JAVA_HOME=$HOME/jdk-21.0.2 mvn clean release:prepare -Dresume=false

$ JAVA_HOME=$HOME/jdk-21.0.2 mvn release:perform

[eamonnmcmanus]

Thanks @cpovirk for those helpful comments! I've got as far as you, and am hitting the same error about test-graal-native-image. It seems to me that it should be skipped because of this clause from the commit you mentioned earlier:

          <configuration>
            <skipPublishing>${gson.isInternalModule}</skipPublishing>
          </configuration>

and given this earlier definition in the main <properties>:

    <!-- Whether this module is internal and currently not deployed -->
    <gson.isInternalModule>${gson.isTestModule}</gson.isInternalModule>

test-graal-native-image/pom.xml does define gson.isTestModule.

I'm going to see what else I can make work. This is all unfortunately a bit tedious because it takes several minutes each time before you get to the point where it fails.

[eamonnmcmanus]

OK, some progress. I was able to get past the issue with test-graal-native-image by putting this in its pom.xml:

      <plugin>
        <groupId>org.sonatype.central</groupId>
        <artifactId>central-publishing-maven-plugin</artifactId>
        <configuration>
          <skip>true</skip>
        </configuration>
        <executions>
          <execution>
            <id>central-publishing</id>
            <phase>none</phase>
          </execution>
          <execution>
            <id>injected-central-publishing</id>
            <phase>none</phase>
          </execution>
        </executions>
      </plugin>

I think probably only the injected-central-publishing bit is needed. That was the last thing I added. The <skip>true</skip> and <id>central-publishing</id> parts were earlier attempts that failed.

So now the whole process finishes, but it doesn't look as if it has actually published anything. There's a lot of output, most of it for modules we're not interested in, but if I scroll up far enough I see this:

[INFO] [INFO] --- central-publishing:0.8.0:publish (injected-central-publishing) @ gson ---
[INFO] [INFO] Using Central baseUrl: https://central.sonatype.com
[INFO] [INFO] Using credentials from server id central in settings.xml
[INFO] [INFO] Using Usertoken auth, with namecode: [redacted]
[INFO] [INFO] Staging 7 files
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1.jar
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1.jar to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1.jar
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/pom.xml to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1.pom
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-sources.jar
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-sources.jar to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1-sources.jar
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-javadoc.jar
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-javadoc.jar to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1-javadoc.jar
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1.jar.asc
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1.jar.asc to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1.jar.asc
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1.pom.asc
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1.pom.asc to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1.pom.asc
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-sources.jar.asc
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-sources.jar.asc to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1-sources.jar.asc
[INFO] [INFO] Staging /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-javadoc.jar.asc
[INFO] [INFO] Installing /[my-homedir]/gson/target/checkout/gson/target/gson-2.13.2-rc1-javadoc.jar.asc to /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/2.13.2-rc1/gson-2.13.2-rc1-javadoc.jar.asc
[INFO] [INFO] Pre Bundling - deleted /[my-homedir]/gson/target/checkout/target/central-staging/com/google/code/gson/gson/maven-metadata-central-staging.xml
[INFO] [INFO] Generate checksums for dir: com/google/code/gson/gson/2.13.2-rc1
[INFO] [INFO]
[INFO] [INFO] -------------------< com.google.code.gson:test-jpms >-------------------
...

If I compare that to the documentation, I should be seeing additional messages like this:

[INFO] Going to create /central/tests/sonatype-central-example/target/central-publishing/central-bundle.zip by bundling content at /central/tests/sonatype-central-example/target/central-staging
[INFO] Created bundle successfully /central/tests/sonatype-central-example/target/central-staging/central-bundle.zip
[INFO] Going to upload /central/tests/sonatype-central-example/target/central-publishing/central-bundle.zip
[INFO] Uploaded bundle successfully, deployment name: Deployment, deploymentId: 9590fb21-a026-4451-9722-a7216b258f4d. Deployment will require manual publishing
[INFO] Waiting until Deployment 9590fb21-a026-4451-9722-a7216b258f4d is validated
[INFO] Deployment 9590fb21-a026-4451-9722-a7216b258f4d has been validated. To finish publishing visit https://central.sonatype.com/publishing/deployments

What I'm seeing seems similar to this, where the author said they had figured out that it was a problem with a self-developed plugin.

[eamonnmcmanus]

OK, I'm giving up for today. A snapshot of my flailing is in #2899. mvn -X release:perform shows no useful information beyond what I quoted above.

[Marcono1234]

So now the whole process finishes, but it doesn't look as if it has actually published anything.

Tried to reproduce it myself as well now. For the last module (proto) it prints:

...
[INFO] [INFO] Generate checksums for dir: com\google\code\gson\proto\2.13.3
[INFO] [INFO] Going to create C:\...\gson\target\checkout\target\central-publishing\central-bundle.zip by bundling content at C:\...\gson\target\checkout\target\central-staging
[INFO] [INFO] Created bundle successfully C:\...\gson\target\checkout\target\central-staging\central-bundle.zip
[INFO] [INFO] Skipping Central Release Publishing at user's request.

So it seems it performs the publishing for all modules as part of the last module; see also plugin source code (unofficial mirror¹).

Apparently skipPublishing is not the right choice then. Instead, maybe we have to configure the plugin for all modules which should be published, and only for those, not the parent POM.

Also, I had a look inside the target\central-staging\central-bundle.zip file, and it seems the .buildinfo files are missing. Not really a big problem as long as the build is still reproducible²; and maybe when deploying to Central those files are included? I guess we will see.

Footnotes

1. By now this seems to be more than a "mirror" because the maintainer has also included third-party changes and published the plugin under their own coordinates. ↩

2. The .buildinfo file just makes it easier to reproduce the build because it describes the build setup (OS, Java version, ...). ↩

[eamonnmcmanus]

Oh, interesting! And a bit weird, but whatever. Let me try your suggestion. I believe the only module we actually need to publish is gson. We currently also publish gson-parent but all it contains is a pom.xml.

[cpovirk]

gson does depend on gson-parent, so I think we'd need to either break that dependency or else publish both:

gson/gson/pom.xml

Line 22 in 69cb755

<artifactId>gson-parent</artifactId>