CI: Update maven plugins and release pipeline - migrate from OSSRH to central publishing

[pietrygamat]

OSSRH, a service we used in the past to publish JSSC releases to Maven Central, announced that it's reaching its end of life, and users should migrate to the successor service - Central Portal. Instructions are available at this link.

For JSSC this means:

• Updating maven plugins (replace org.sonatype.plugins:nexus-staging-maven-plugin with org.sonatype.central:central-publishing-maven-plugin)
• Updating Github Action secret (new deployment token is required to be configured in Github repository settings)
• Migrating Namespace to Central Portal (to be done by one of the project maintainers).

In this PR I sorted out the code side changes, plus a few minor additions:

• Updated most of the maven plugins to their latest versions
• Renamed some pom.xml properties indicating versions of core maven plugins - this is in order to follow the reserved pattern for plugins developed by Apache Maven team with a bonus of having them grouped together when sorted alphabetically.
• Changed the release pipeline so that it automatically marks the github release as a prerelease - to give maintainers some time to update the description and do some last minute testing before notifying watchers.

[tresf]

LGTM.

Do you think this warrants re-publishing the 2.10.0 tag so we have confidence by "testing" this now or are you comfortable with shelving this until 2.10.1, etc?

[pietrygamat]

Do you think this warrants re-publishing the 2.10.0 tag so we have confidence by "testing" this now or are you comfortable with shelving this until 2.10.1, etc?

We can't really re-publish the same version of artifact to Maven Central, but I have just executed the pipeline on test branch and pushed a 2.10.1-alpha1. It is pending manual confirmation both in Github releases page as well as in Central Publishing portal, so it seems to work as expected. I guess we don't have to verify the actual publish action on their side just yet.

[tresf]

We can't really re-publish the same version of artifact to Maven Central

This makes perfect sense... I think I was under the false impression that it wouldn't publish to Maven under prerelease tag, buying us the "testing" mentioned here:

Changed the release pipeline so that it automatically marks the github release as a prerelease - to give maintainers some time to update the description and do some last minute testing before notifying watchers.

Not making any criticism though, this is what the patch process is for, so it's all working as expected. We may very well have other regressions we won't know until users deploy.

[tresf]

I have just executed the pipeline on test branch and pushed a 2.10.1-alpha1. It is pending manual confirmation both in Github releases page as well as in Central Publishing portal, so it seems to work as expected. I guess we don't have to verify the actual publish action on their side just yet.

Is there an easy way to provide a build that includes #189 so that I can test it with macOS notarization?

[pietrygamat]

After running this action from Github on a specific branch, you end up with another branch where new binaries are pushed. If you are happy with the result, the latter branch may be merged to master (ideally without rebase/squash to preserve the relation between CI job and the resulting commit). If there is a problem, or a need to retry, drop the autogenerated, and retry after fixing it.

[tresf]

After running this action from Github on a specific branch, you end up with another branch where new binaries are pushed. If you are happy with the result, the latter branch may be merged to master (ideally without rebase/squash to preserve the relation between CI job and the resulting commit). If there is a problem, or a need to retry, drop the autogenerated, and retry after fixing it.

Thanks. This may seem obvious but if you could help me and other collaborators understand how to run this step for the future, that would be greatly appreciated.

WRT testing #189, that seems off-topic now, but to finish the conversation... I can build a jar locally from this that branch to test notarization; In the future perhaps we add an actions-artifact-upload step to make the jars readily available for testing as well. This would reduce any variables introduced by a local build environment. I'll report my findings.

[tresf]

I'll report my findings.

Notarization is fixed with the merge of #189.

  Conducting pre-submission checks for <redacted>.pkg and initiating connection to the Apple notary service...
  Submission ID received
    id: d2ff4d2c-abcd-4afe-a1aa-5ba2b71ac818
  Upload progress: 100.00% (99.3 MB of 99.3 MB)   
  Successfully uploaded file
    id: d2ff4d2c-abcd-4afe-a1aa-5ba2b71ac818
    path: <redacted>.pkg
  Waiting for processing to complete.
+ Current status: Accepted.................
  Processing complete
    id: d2ff4d2c-abcd-4afe-a1aa-5ba2b71ac818
+   status: Accepted
  Processing: <redacted>
  Processing: <redacted>
+ The staple and validate action worked!

[pietrygamat]

if you could help me and other collaborators understand how to run this step for the future, that would be greatly appreciated.

I have updated the Wiki.

[tresf]

if you could help me and other collaborators understand how to run this step for the future, that would be greatly appreciated.

I have updated the Wiki.

Thanks!