[stippi2]

The perform_release workflow is changed to deploy to Maven Central instead of Artifactory/Snapshots. The signing of the JARs and other artifacts is achieved by replacing the Maven Deploy plugin with the Maven GPG plugin. Accordingly, the GPG key is imported from the GitHub secrets and the plugin will take care of generating .asc files for every artifacts. First we deploy to a local repository which we then deploy to Maven Central via nexus-staging-maven-plugin:deploy-staged-repository. This creates a temporary staging repository which is automatically closed and validated. The -DautoReleaseAfterClose=false line would need to be changed to true in order to automatically promote the release.

[CharlesDuboisSAP]

Generally LGTM but why do you need to push to a local repository?

[stippi2]

Generally LGTM but why do you need to push to a local repository?

In the end, this was the easiest way to integrate both the GPG plugin and the nexus staging plugin into our existing solution without major changes. The nexus staging plugin usually replaces the deploy plugin. Initially we created the JAR signatures as part of the original build (prepare_release), but then we could not keep these signatures attached to the artifacts when we replace the deploy plugin with nexus staging. So instead, we replace the deploy plugin with the GPG plugin, which has the exact same configuration in the execution blocks, but generates the signature files. But then we cannot directly deploy to nexus staging. Instead, we deploy to a local repository. The nexus staging plugin in turn has a feature where it can simply deploy such a local repo to Maven Central. Overall it results in the minimal changes.