ci: tim-brown Update POMs for building of BOMs and migration to maven central publishing portal

[tim-brown]

Releases of Ocava have not been deployed to maven central for some time now. I have tried to fix this (frankly, so I can show off Lookup)... and discovered/fixed a few fun things.

From a branch on my fork, I have managed to draft a release, running the release action. It builds, tests, and invokes the central-publishing-maven-plugin. Pipeline fails with:

Error:  
Deployment 652c6230-fcf4-441e-a40c-c6578b32f74b failed
pkg:maven/com.ocadotechnology/ocava-open-source-bom@v17.18.0-exp.5?type=pom:
 - Invalid signature for file: ocava-open-source-bom-v17.18.0-exp.5.pom.asc
 - Namespace 'com.ocadotechnology' is not allowed
[... for each package...]

I think this is as far as I can go... my sonatype account won't allow me to publish com.ocadotechnology artifacts; and the signature is not going to be signing the wrong thing. So attached to this PR is the full error report; evidencing that I've got as far as I could before failure.

I acknowledge there is a fairly large number of critical design decisions I have made here; but I think you'll need to deal with the OSSRH → central migration sooner or later (and the deadline is rocking up pretty quick). OTOH, I'll take no offense if you just use this PR as inspiration. Good luck with it.

Note this is a ci semantic change, so it won't trigger a release; anyway, I guess that after reading the PR, you'll want to hand-hold this through.

maven-release.yml, maven.yml:

• there were whinges about the github actions setup scripts Ocava is using; updating them to version @2 seems to have shut this up
• the BoM was not being versions:set, meaning that later in the build, bom:(new-version) isn't found: this is handled with versions:set -DprocessAllModules

Sonatype is migrating away from publishing via OSSRH to a new central publishing mechanism. I touch on it in one of my comments: https://central.sonatype.org/publish/publish-portal-maven, but this is by far not the extent of the reading. There are new secrets to be managed, and I think these will be global to com.ocadotechnology, I don't know how the internal open source community works there, but aligning on this might be worthwhile. So .mvn/settings.xml and maybe pom.xml and BoM/pom.xml will need better secrets (PGP, maybe, but probably not) management than I have here.

All **/pom.xml:

• in the new process, released artifacts need <licences>, <developers>, <scm> and <name>; the first three are inherited from parent pom.xml, but <name> had to be added to all POMs.

.mvn/settings.xml:

• the Sonatype tooling uses a server called central. I have added an entry here for central, but I'm still using ossrh_login ossrh_passwordsecret environment variables. You will need to manage this better. Leaving the two entries hopefully allows for a smoother migration, but you should be aiming at removing theossrh` entry.

Parent pom.xml:

• I thought, originally, for the previous point that this was something to not finding the artifact on bintray. Looking into it, the bintray service has been discontinued. That seems to have been well before Ocava releases stopped. But it couldn't have helped. I've left the repository identified as bintray, but pointed it at central... you need a repository. I really think this needs thinking through a bit more thoroughly. But it seems to work.
• migrated from nexus-staging-maven-plugin to central-publishing-maven-plugin: distribution repositories are implicitly central, and need new credentials
• bumped deploy.plugin.version: some part of this process didn't seem to work with this
• removed distributionManagement: central-publishing-maven-plugin defines its own distribution targets (you can override them, but why?). It seems a bit odd to me that you are building an OSS artifact, then distributing it exclusively to your internal nexus. My suggestion is start with this configuration (distribute to central); let your nexus mirror pick up from central, and only if that is too slow/broken try to distribute directly to your nexus... I might be missing something.

BoM/pom.xml:

• I found that for some reason this stands separate to the rest of the modules in the project even though it's mentioned in the pom.xml -- why? I can't fathom... but AFAICT, it needs these two plugins mentioned for the release profile. The plugin definitions are identical to pom.xml
• removed distributionManagement: for the same reason as parent pom.xml
• again, BoM/pom.xml did not inherit the required metadata, so <licences>, <developers>, <scm> and <name> have been copied in from parent pom.xml

[colin-janke]

Thanks Tim! I don't expect I'll get to looking at this soon, but I have raised it internally to see if anyone wants to use this opportunity to learn about this stack.

[mvy]

BoM/pom.xml:

I found that for some reason this stands separate to the rest of the modules in the project even though it's mentioned in the pom.xml -- why? I can't fathom...

There is a reason why the BoM stands apart. It needs to not include the project dependencies, as this would force downstream project to use these dependencies with the specified version in some circumstances. This is due to how maven handles dependency versions when compiling (shallowest then first in a breadth first search of the dependency tree).

The solution I have found to do this is to make sure the BoM is on its own, and does not reference a parent.

but AFAICT, it needs these two plugins mentioned for the release profile. The plugin definitions are identical to pom.xml

I was not aware of these requirements, but this makes sense.

removed distributionManagement: for the same reason as parent pom.xml
again, BoM/pom.xml did not inherit the required metadata, so , , and have been copied in from parent pom.xml

The BoM will definitely need some duplication similar to the parent pom because of that separation need.