[Sreini]

Publishing 1.9.0 to Maven Central failed validation (run 41844578310):

Deployment 00dd1f25-7b33-480f-9e10-aebd3694a7cd failed
common:
 - Bundle has content that does NOT have a .pom file: com/tinify/tinify

Cause

ubuntu-24.04 image 20261101.360 ships Maven 3.10.0. 3.10.0 writes maven-metadata-local.xml and _remote.repositories into the local-repository layout that central-publishing-maven-plugin stages from. 0.7.0 bundles the staging directory as-is, so the uploaded zip contains:

com/tinify/tinify/maven-metadata-local.xml

A file at the artifact level, with no version directory and therefore no .pom beside it — which is the path Central names verbatim in the error.

Reproduced

Same pom, same command, Maven 3.10.0 (checksum-verified from archive.apache.org), -Dgpg.skip:

com/tinify/tinify/maven-metadata-local.xml          <- stray
com/tinify/tinify/1.9.0/_remote.repositories        <- stray
com/tinify/tinify/1.9.0/tinify-1.9.0.jar
...

The identical build under Maven 3.9.15 produces a clean 20-file tree. That is why this never reproduced locally, and why the failure looked like a packaging problem rather than a toolchain one.

Fix verified

0.12.0 strips them before bundling:

[INFO] Pre Bundling - deleted .../com/tinify/tinify/maven-metadata-local.xml
[INFO] Pre Bundling - deleted .../com/tinify/tinify/1.9.0/_remote.repositories
[INFO] Pre Bundling - deleted .../central-staging/.locks

Resulting bundle: 20 files, the same shape as 1.8.8 on Central. The run then fails only on the dummy credentials I used (401 on upload), which is as far as I can verify without the real secrets.

Also adds --show-version so the Maven version is in the log — its absence is most of why this took a while to find.

Not in this PR

• 1.8.9 (tagged 2026-03-17) never reached Central either. That pom still used nexus-staging-maven-plugin against OSSRH, which was already sunset — a different failure with the same symptom of a silent non-release. Central's latest is still 1.8.8.
• The publish command runs org.apache.felix:maven-bundle-plugin:bundle explicitly and via the bundle packaging lifecycle, so the goal executes twice (default-cli then default-bundle), about 25s wasted. Harmless, left alone.

After merging

The 1.9.0 tag points at the pre-fix commit, so the publish job will not re-run on it by itself. Nothing was published under 1.9.0, so either the tag gets moved to the merge commit or 1.9.1 gets cut — your call.

🤖 Generated with Claude Code