Maven Central Publish requirements — check your pom in browser

Sixteen blocking findings in one 78-line pom.xml. That is what the gate returned on a Java library whose maintainer, a solo open-source developer in Rotterdam, had already tagged, built and signed, ten minutes before mvn deploy.

None of the sixteen were compile errors. mvn verify was green. That is the whole trap: the Maven Central Portal validates publishing metadata that the build itself never reads, so a POM can be perfectly buildable and still be rejected at upload.

The biggest one was infrastructure. Sonatype closed oss.sonatype.org to releases on 2025-06-30. The POM still pointed distributionManagement there, and still drove the release with nexus-staging-maven-plugin, the plugin that retired alongside it. Two lines, written when that was the correct answer, and correct nowhere since.

This is exactly the kind of line a generated build file gets wrong. Ask an assistant to set up Central publishing and much of what comes back is the OSSRH staging flow, because that is what most of the internet still describes. The code compiles. The release does not land.

The rest were ordinary and just as fatal. The version was 2.4.0-SNAPSHOT, and Central does not accept SNAPSHOT bundles. One dependency was itself a SNAPSHOT, which would have made the published artifact unbuildable downstream even if the upload had landed. gpg.skip was true from a CI experiment, so nothing would have carried an .asc signature. A vendor jar was wired in with system scope and a local systemPath, pointing at a file that exists on exactly one laptop. An internal mirror was declared over plain http://, blocked by Maven itself since 3.8.1.

And four required metadata blocks were simply absent: description, licenses, developers, scm. The Portal requires all of them. There was no maven-source-plugin and no maven-javadoc-plugin, so no -sources.jar and no -javadoc.jar would have been attached, and Central requires both.

Fifteen errors and one warning, raised by 13 of the gate's 16 rules, on 78 lines.

Run the same gate against a release-ready POM and it returns nothing. The clean fixture that ships with the extension is 99 lines and produces 0 findings. Both files ship, so you can check the claim yourself before you trust it with a release.

The shutdown date is a real input, not a constant in a sentence. Hand the gate a date before 2025-06-30 and the OSSRH finding reads 'Sonatype closes it to releases on 2025-06-30 — move the deploy before that date.' Hand it today's date and it reads 'closed on 2025-06-30. Deploy to the Central Portal instead.' Same rule, same file, different answer.

What it does not do: it reads the POM as text. It does not resolve parent POMs, interpolate properties, contact the Portal, or read your settings.xml or keyring. A file that passes can still fail on something only Sonatype knows, such as an unverified namespace.

A rejected bundle is not a five-minute fix. You retag, rebuild, re-sign, re-upload. A freelance Java release engineer bills about $80 an hour, and the round-trip eats more than the review would have. Worse, a version number you burned on a failed attempt is gone for good.

The free version checks the pom.xml you have open, every rule, no key and no cap. That is a finished job — you see the blockers, you fix them, you ship. The licensed version changes the scope: it gates every pom.xml in a multi-module repository in one pass and writes the result to a REPORT.md you keep.