▌ Phosphor

Publishing 0.1.1: The Deploy That Exited 0 and Published Nothing

September 23, 2026

jterm 0.1.1 is on Maven Central. The build that put it there was green in seventeen seconds of test time — and took nine and a half minutes of wall clock, plus a mid-flight correction when we discovered the first deploy had quietly published nothing at all. This post is the release notes for the process, because the failure mode is one every maintainer of a Central-published library will hit.

The ceremony around 18 seconds of tests

The release profile layers four slow things on top of a fast suite:

  1. Zero-warning javadoc. Every public member documented or the build fails. It’s the single slowest local phase (~2 minutes for jterm’s 4,000-public-API codebase) and it’s non-negotiable — Central rejects broken javadoc jars, and a jar built from warnings is how broken docs get published.
  2. Sources jar + GPG signing of all four artifacts (main, sources, javadoc, pom). Each signature is generated and verified before upload.
  3. Bundle upload to the Central Portal — the plugin assembles everything into one zip and pushes it.
  4. The portal poll. With waitUntil=published, the Maven build blocks until Sonatype’s validators finish and the artifacts propagate to repo1.maven.org. This is pure server-side time. Your build is done; you’re waiting for theirs.

None of this shows up in development, where mvn test is the whole story. It’s why a release deploy is ~10 minutes while mvn test is under 30 seconds.

The trap: exit code 0, nothing published

The pom’s central-publishing plugin had:

<autoPublish>false</autoPublish>
<waitUntil>published</waitUntil>

With autoPublish=false, the deploy uploads the bundle to the Central Portal and stops. The artifacts sit in the portal’s deployment list, fully validated, awaiting a human click on “Publish.” And here’s the trap: mvn deploy exits 0. BUILD SUCCESS. The log even says the bundle uploaded successfully.

Nothing is on Maven Central. The maven-metadata on repo1.maven.org still shows the old release. But your terminal says success, and if your release procedure’s next step is “tag, push, bump to next -SNAPSHOT” — you’ve now got a release that lives only in the portal dashboard and a repository that has already moved on.

The failure mode is especially cruel because it’s deterministic in the wrong direction: every check you’d write for a CI pipeline (exit code, build status, “deploy completed”) passes. The only check that works is querying the actual CDN:

curl -s https://repo1.maven.org/maven2/io/jterm/jterm/maven-metadata.xml | grep release

Until that shows your version, the release does not exist.

The 403 that tells you what you did wrong

The obvious fix — flip autoPublish to true and redeploy — has its own teeth. If you’ve already done the post-release version bump (we had: 0.1.2-SNAPSHOT), a re-deploy from that tree tries to publish the snapshot to the snapshots repository, which the portal rejects with a bare 403 Forbidden. Same build command, same profile, wrong version entirely.

The clean recovery: branch off the release commit (where the pom still says 0.1.1), flip autoPublish=true there, redeploy — identical artifacts re-upload fine, hashes and all — and delete the branch. Main stays on its -SNAPSHOT. The deploy now prints the line that matters:

Deployment will publish automatically … was successfully published

What 0.1.1 actually shipped

Worth listing, because release posts usually bury it: the CommonMark-lite MarkdownWidget and parser, a real thread-safety fix in DefaultGridModel (atomic row mutators — its own post), bbs.debug wire-decode tracing in SocketTerminal, modal-gate keystroke preservation, per-column Table width constraints, and zoom screen transitions. 2,926 tests green at the gate.

The procedure, updated

The release procedure now has the ordering baked in — and the order is the whole point:

  1. Full suite green on main.
  2. Version bump + commit.
  3. mvn clean verify -Prelease — the gate.
  4. mvn deploy -Prelease — with autoPublish=true, or expect to manually publish in the portal.
  5. Verify on repo1.maven.org first. Then tag, push, bump to next -SNAPSHOT.

That last clause is the scar tissue: the version bump happens after the CDN shows the release, not after the deploy exits. A deploy that exits 0 is a claim; metadata on the CDN is a fact. Publish the fact, then move on.