A release goes to Maven Central

[tamnd]

The version properties for maven-gpg-plugin and central-publishing-maven-plugin have been in the parent pom since the repository was laid out and neither plugin was ever configured, so mvn deploy would have put the artifacts nowhere at all. This wires both up and adds the workflow that runs them.

One upload for the whole reactor rather than one per module. Central validates a deployment as a unit, and a half-published version is a version nobody can use and nobody can replace. autoPublish is off, so a tag produces a deployment sitting in the portal and nothing more, and dropping it there is the only undo that exists once a version has gone out.

The version lives in the tag rather than in the pom. v0.11.0 builds 0.11.0 with versions:set and never commits it, because a repository whose version has to be bumped before every release is a repository where a checkout between the bump and the tag claims a version that was never built.

The engine and this client move on one number, so the same tag names the engine release the libraries are downloaded from, and the suite then runs against the very library that is about to be published rather than against a build of main. A release that cannot answer a query does not go out.

Central wants a sources jar and a javadoc jar beside every jar it publishes and has no way of being told that an artifact made of shared libraries has neither. So zudb-native attaches both by hand and both hold one file explaining why they are empty, which is more use to whoever opens one than a jar with nothing in it, which reads like a build that went wrong.

gpg runs with --pinentry-mode=loopback, because a release runs where there is no terminal and the default is to try to open one and hang until the job is cancelled.

A dispatch with publish unticked does everything up to the upload, so the packaging can be changed and checked without spending a version on it.

Locally mvn -Prelease,natives -DskipTests -Dgpg.skip=true package produces the ten zudb-native jars and sources and javadoc for zudb and zudb-ffm, and mvn -Prelease -DskipTests package, which is what the javadoc job in CI runs, is unchanged. Four secrets are needed before a tag will work: CENTRAL_USERNAME, CENTRAL_PASSWORD, GPG_PRIVATE_KEY and GPG_PASSPHRASE.