feat(maven): publish both artifacts to maven central

[andiwand]

Stacked on #629.

GitHub Packages demands read:packages even to read a public artifact. f-droid builds from source with no credentials at all, so it cannot resolve either artifact from there — and being consumable by droid, which f-droid builds, is the whole reason the AAR exists. #629 says this needs Maven Central "first, which is a separate piece of work — the app.opendocument namespace has to be verified, and every artifact signed." Half of that turned out to be already done.

app.opendocument is not a new namespace

The org has published android AARs to Maven Central before, under exactly this group:

artifact	latest	published
app.opendocument:pdf2htmlex-android	0.18.26	2024-08-25
app.opendocument:wvware-android	1.2.11	2024-08-26

Both are on repo1.maven.org today, and droid consumed them as ordinary mavenCentral() dependencies before they were archived. So this is a new artifact under an established name. What is genuinely outstanding is credentials, not verification — see below.

What this changes

The AAR goes through com.vanniktech.maven.publish. Sonatype ships no official gradle plugin for the Central Portal, and OSSRH — which pdf2htmlEX-Android and wvware-android deployed to — is gone, so their gradle-nexus/publish-plugin + s01.oss.sonatype.org setup cannot simply be copied. vanniktech is what android libraries have settled on. It renames the publication release → maven, so the workflow now asks for the name-independent publishAllPublicationsToGitHubPackagesRepository.

The jar keeps its hand-written pom and gains a central profile. central-publishing-maven-plugin takes over the deploy lifecycle wholesale, so one mvn deploy cannot serve both destinations; the default stays GitHub Packages and -Pcentral is the Central path. maven.yml splits publishing into its own job so the secrets sit behind an environment, the shape android.yml already has.

Both keep publishing to GitHub Packages. Nothing that reads it today breaks.

Central asks for more than GitHub Packages does, and both artifacts now supply it:

• sources and javadoc jars — the jar already had them, the AAR now does;
• a POM carrying developers — neither had one, so neither would have been accepted as it stood;
• a PGP signature over every file.

Signing is conditional on a key being configured. Unconditional (signAllPublications() on its own) fails publishToMavenLocal with "no configured signatory", which would mean nobody could publish locally or to GitHub Packages without a private key on hand — a steep price for two destinations that never check one. The portal rejects an unsigned upload, so the release path stays guarded.

Both publishes upload a deployment and stop. Releasing is a deliberate click in the portal UI: Central never forgets a version, and that click is the last point at which a bad artifact can be dropped rather than lived with.

Verification

Locally, against a throwaway PGP key: the AAR publishes .aar, .pom, .module, sources and javadoc jars, each with a detached .asc that verifies against the key; the POM carries name, description, url, licenses, developers and scm; the AAR still contains its assets and prebuilt ABIs. With no key set it publishes the same artifacts unsigned. mvn verify and mvn validate -Pcentral both pass, and the flattened pom keeps developers.

Not verified: an actual upload to the portal, which needs credentials this repo does not have yet.

Before this can release

The maven-central environment has to exist with four secrets:

secret	what
MAVEN_CENTRAL_USERNAME / MAVEN_CENTRAL_PASSWORD	Central Portal user token, generated at central.sonatype.com — not portal login credentials
SIGNING_KEY	armored PGP private key
SIGNING_PASS	its passphrase

The archived repos hold a working SIGNING_KEY/SIGNING_PASS pair in their own OpenDocumentAppRelease environment, so the signing key may just need copying. The Sonatype credentials do not carry over: those are OSSRH-era, and the Portal issues its own tokens. Worth confirming who holds the Portal account that owns the app.opendocument namespace, since these repos came from an outside author.

🤖 Generated with Claude Code