SK-3002 bump central-publishing-maven-plugin to 0.11.0 for the Portal API - #402
Conversation
… API
The flowvault/v1.0.0 release built, tested, signed and uploaded all 11
artifacts, then died reading the Central Portal's reply:
UnrecognizedPropertyException: Unrecognized field "warnings"
(class org.sonatype.central.publisher.client.model.DeploymentApiResponse),
not marked as ignorable
The Portal added a "warnings" field to the deployment-status response.
Pinned 0.4.0 does not know it and does not ignore unknown properties, so
the goal throws - after the bundle is already on the server, which is the
worst place to fail.
0.11.0 is the first version that fixes it. Checked every release in
between; DeploymentApiResponse fields are:
0.5.0 / 0.7.0 deploymentId, deploymentName, deploymentState,
purls, errors, cherryBomUrl
0.8.0 / 0.9.0 / 0.10.0 ... errors
0.11.0 ... errors, warnings
So 0.5.0-0.10.0 would all fail identically - there is no smaller bump.
tokenAuth is dropped because it stopped being a plugin parameter in
0.5.0; 0.11.0 exposes publishingServerId and autoPublish, both kept.
Token auth is now the only mode and comes from the server credentials.
0.11.0 targets Java 8, so it still runs on the release JDK 11.
Verified with 'mvn -pl flowvault -am -P maven-central deploy': the
0.11.0 goal resolves, binds and executes with this configuration, no
unknown-parameter complaints; it stops only at the missing local
'central' server credentials, which CI supplies.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
✅ Gitleaks Findings: No secrets detected. Safe to proceed! |
|
Semgrep Findings: Issues with Error level severity are found (Error is Highest severity in Semgrep), Please resolve the issues before merging. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #402 +/- ##
==========================================
Coverage 91.30% 91.30%
- Complexity 0 454 +454
==========================================
Files 157 157
Lines 6392 6392
Branches 850 850
==========================================
Hits 5836 5836
Misses 364 364
Partials 192 192
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
Correction to the follow-up note in this PR's description: Handled properly in #404 instead, via shade's |
The flowvault/v1.0.0 bundle staged 11 files, two of which are
build-internal and were about to become permanent public classifiers:
skyflow-flowvault-java-1.0.0-tests.jar
skyflow-flowvault-java-1.0.0-with-common.jar
Both were published for the same reason: they are ATTACHED as secondary
artifacts, and deploy uploads every attached artifact.
-with-common is the japicmp comparison jar. skyvault/pom.xml already
described it as "comparison-only", but shadedArtifactAttached is exactly
what attaches it, so the comment's intent was never enforced. Replaced
with shade's outputFile, which writes the jar and neither replaces the
main artifact nor attaches it. The output path is unchanged, so the
japicmp newVersion path needs no edit.
-tests came from the root pom's maven-jar-plugin test-jar execution,
inherited by every module. Nothing in the repo consumes a test-jar
(no <type>test-jar</type> dependency anywhere) and the release build's
tests run in-module, so the execution is removed.
Note excludeArtifacts on central-publishing-maven-plugin is NOT a usable
alternative: its filter compares against Artifact.getArtifactId(), not
the classifier, so listing skyflow-flowvault-java would drop the main
jar too.
Verified with 'mvn clean install' over the whole repo. Every module now
attaches exactly jar + sources + javadoc:
common-1.0.0{,-sources,-javadoc}.jar
skyflow-java-2.1.1{,-sources,-javadoc}.jar
skyflow-flowvault-java-1.0.0{,-sources,-javadoc}.jar
japicmp:cmp still runs and passes for both skyvault and flowvault, and
target/*-with-common.jar is still produced on disk for it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
✅ Gitleaks Findings: No secrets detected. Safe to proceed! |
|
Semgrep Findings: Issues with Error level severity are found (Error is Highest severity in Semgrep), Please resolve the issues before merging. |
1 participant
Problem
flowvault/v1.0.0failed again (run 30827236957) — a different failure from the javadoc one fixed in #400. The build fully succeeded: tests, javadoc, GPG signing, all 11 artifacts staged. It then died reading the Central Portal's reply:The Portal added a
warningsfield to the deployment-status response. Pinned0.4.0doesn't know it and doesn't ignore unknown properties, so the goal throws — after the bundle is already uploaded, which is the worst possible place to fail.Why 0.11.0 specifically
I checked every release in between rather than jumping to latest on faith.
DeploymentApiResponsefields per version:0.5.0–0.10.0would all fail identically. There is no smaller bump — 0.11.0 is the first version that works.Why
tokenAuthis removedIt stopped being a plugin parameter in
0.5.0. Verified against 0.11.0'sMETA-INF/maven/plugin.xml:publishingServerIdandautoPublishare both still present,tokenAuthis absent. Token auth is now the only mode and is driven by the server credentials, so behaviour is unchanged.autoPublish=falseis preserved in both modules — releases still stage as VALIDATED and wait for a human.Compatibility
0.11.0 targets Java 8, so it runs fine on the release JDK 11.
Verification
The 0.11.0 goal resolves, binds and executes with this exact configuration, with no unknown-parameter complaints. It stops only at the missing local
centralserver credentials — which CI supplies viaactions/setup-java. That's as far as this can be verified without publishing.The failed run already uploaded the bundle. Staging completed and the Portal responded with a
deploymentId, so a deployment forcom.skyflow:skyflow-flowvault-java:1.0.0almost certainly exists at https://central.sonatype.com/publishing/deployments.Nothing went live (
autoPublish=falseheld), so Central's immutability hasn't been triggered.The 11 staged files include two that look unintended for Maven Central:
skyvault/pom.xmldescribes thewith-commonjar as comparison-only:But
shadedArtifactAttached=trueattaches it as a secondary artifact, anddeployuploads every attached artifact — so a jar documented as build-internal is being published as a permanent public classifier, alongside a-tests.jar.Not fixed here, to keep this PR to the release blocker. 0.11.0 does add an
excludeArtifactsparameter that would handle it cleanly if you want that as a follow-up. Worth settling before clicking Publish, since these coordinates become permanent.🤖 Generated with Claude Code