From 2cf952ee196567c63b047b6ba78d3de0c42b87f9 Mon Sep 17 00:00:00 2001
From: Devesh-Skyflow <devesh.bhardwaj@skyflow.com>
Date: Mon, 3 Aug 2026 21:29:27 +0530
Subject: [PATCH 1/2] SK-3002 bump central-publishing-maven-plugin to 0.11.0
 for the Portal 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>
---
 flowvault/pom.xml | 10 ++++++++--
 skyvault/pom.xml  |  4 ++--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/flowvault/pom.xml b/flowvault/pom.xml
index 2b276145..e30ff575 100644
--- a/flowvault/pom.xml
+++ b/flowvault/pom.xml
@@ -203,11 +203,17 @@
                     <plugin>
                         <groupId>org.sonatype.central</groupId>
                         <artifactId>central-publishing-maven-plugin</artifactId>
-                        <version>0.4.0</version>
+                        <!-- 0.11.0, not 0.4.0: the Portal's deployment-status response gained a
+                             "warnings" field, and every client before 0.11.0 fails to deserialize
+                             it (UnrecognizedPropertyException), aborting the release *after* the
+                             bundle has already been uploaded. 0.11.0 is the first version whose
+                             DeploymentApiResponse knows the field. tokenAuth is gone with the
+                             upgrade - it stopped being a plugin parameter in 0.5.0; token auth is
+                             now the only mode, driven by the server credentials. -->
+                        <version>0.11.0</version>
                         <extensions>true</extensions>
                         <configuration>
                             <publishingServerId>central</publishingServerId>
-                            <tokenAuth>true</tokenAuth>
                             <!-- Uploads and validates, then holds the deployment in the
                                  Central Portal as VALIDATED until a human clicks Publish
                                  (or Drop to discard it). Maven Central is immutable - a
diff --git a/skyvault/pom.xml b/skyvault/pom.xml
index 618c7e9d..2b4dc4c6 100644
--- a/skyvault/pom.xml
+++ b/skyvault/pom.xml
@@ -197,11 +197,11 @@
                     <plugin>
                         <groupId>org.sonatype.central</groupId>
                         <artifactId>central-publishing-maven-plugin</artifactId>
-                        <version>0.4.0</version>
+                        <!-- See flowvault/pom.xml for why 0.11.0 and why tokenAuth is gone. -->
+                        <version>0.11.0</version>
                         <extensions>true</extensions>
                         <configuration>
                             <publishingServerId>central</publishingServerId>
-                            <tokenAuth>true</tokenAuth>
                             <!-- See flowvault/pom.xml: releases stage as VALIDATED in the
                                  Central Portal and need a human to click Publish. Note this
                                  changes v2's behaviour - releases no longer go live on their

From c8a8d38be6174638f80aea90c969fbeb9ec51369 Mon Sep 17 00:00:00 2001
From: Devesh-Skyflow <devesh.bhardwaj@skyflow.com>
Date: Mon, 3 Aug 2026 21:39:12 +0530
Subject: [PATCH 2/2] SK-3002 stop publishing build-internal jars to Maven
 Central

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>
---
 flowvault/pom.xml | 20 ++++++++++++--------
 pom.xml           | 15 ++++++---------
 skyvault/pom.xml  | 17 +++++++++--------
 3 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/flowvault/pom.xml b/flowvault/pom.xml
index e30ff575..68b5d9ff 100644
--- a/flowvault/pom.xml
+++ b/flowvault/pom.xml
@@ -78,12 +78,17 @@
                 </executions>
             </plugin>
             <plugin>
-                <!-- Comparison-only jar (classifier "with-common") merging com.skyflow:common,
-                     mirroring skyvault. The published artifact is untouched: shadedArtifactAttached
-                     keeps the main jar as it was. This exists so japicmp compares the whole surface
-                     a consumer actually gets, since classes a customer imports (Credentials,
-                     SkyflowException, BearerToken) live in common and would otherwise read as
-                     missing - japicmp only sees what is physically inside the jars it is given. -->
+                <!-- Comparison-only jar merging com.skyflow:common, mirroring skyvault. This
+                     exists so japicmp compares the whole surface a consumer actually gets, since
+                     classes a customer imports (Credentials, SkyflowException, BearerToken) live
+                     in common and would otherwise read as missing - japicmp only sees what is
+                     physically inside the jars it is given.
+                     Written with outputFile, NOT shadedArtifactAttached: attaching it made it a
+                     secondary artifact, and every attached artifact is deployed, so this
+                     build-internal jar was being published to Maven Central as a permanent
+                     -with-common classifier. outputFile writes the jar and neither replaces the
+                     main artifact nor attaches it. The path is unchanged, so the japicmp
+                     newVersion path below still resolves. -->
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-shade-plugin</artifactId>
                 <version>3.6.0</version>
@@ -95,8 +100,7 @@
                             <goal>shade</goal>
                         </goals>
                         <configuration>
-                            <shadedArtifactAttached>true</shadedArtifactAttached>
-                            <shadedClassifierName>with-common</shadedClassifierName>
+                            <outputFile>${project.build.directory}/${project.build.finalName}-with-common.jar</outputFile>
                             <artifactSet>
                                 <includes>
                                     <include>com.skyflow:common</include>
diff --git a/pom.xml b/pom.xml
index 50d2382e..e9279fd4 100644
--- a/pom.xml
+++ b/pom.xml
@@ -232,15 +232,12 @@
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-jar-plugin</artifactId>
                 <version>3.3.0</version>
-                <executions>
-                    <execution>
-                        <goals>
-                            <goal>test-jar</goal>
-                        </goals>
-                    </execution>
-                </executions>
-                <configuration>
-                </configuration>
+                <!-- No test-jar execution. The 'test-jar' goal ATTACHES the jar as a secondary
+                     artifact, and every attached artifact gets deployed - so it was being
+                     published to Maven Central as a permanent -tests.jar classifier alongside
+                     the SDK. Nothing in this repo depends on a test-jar (no <type>test-jar</type>
+                     dependency anywhere), and the release build's own tests run in-module, so
+                     generating it served no purpose. -->
             </plugin>
             <plugin>
                 <groupId>org.apache.maven.plugins</groupId>
diff --git a/skyvault/pom.xml b/skyvault/pom.xml
index 2b4dc4c6..ce14cc82 100644
--- a/skyvault/pom.xml
+++ b/skyvault/pom.xml
@@ -60,16 +60,18 @@
                 </executions>
             </plugin>
             <plugin>
-                <!-- Produces an additional, comparison-only jar (classifier "with-common")
-                     that merges in com.skyflow:common, same pattern flowvault already uses.
-                     The real published skyflow-java-2.1.1.jar is untouched (shadedArtifactAttached
-                     keeps the main artifact slim) - this attached jar exists only so japicmp can
-                     compare an apples-to-apples "everything a v2 consumer actually gets" surface
+                <!-- Produces an additional, comparison-only jar that merges in
+                     com.skyflow:common, same pattern flowvault already uses. It exists only so
+                     japicmp can compare an apples-to-apples "everything a v2 consumer gets" surface
                      against the old 2.1.0 baseline, which was a single self-contained jar
                      (predating the common/v2 split). Without this, classes that moved into
                      common (Credentials, ErrorCode, BearerToken, Token, etc.) would show up as
                      false-positive "removed" classes, since japicmp only compares what's
-                     physically inside the two jars it's given. -->
+                     physically inside the two jars it's given.
+                     Written with outputFile rather than shadedArtifactAttached: attaching it made
+                     it a secondary artifact, and attached artifacts are deployed, so a jar
+                     documented here as comparison-only was being published. outputFile keeps it
+                     on disk without attaching. Path unchanged, so japicmp still resolves it. -->
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-shade-plugin</artifactId>
                 <version>3.6.0</version>
@@ -81,8 +83,7 @@
                             <goal>shade</goal>
                         </goals>
                         <configuration>
-                            <shadedArtifactAttached>true</shadedArtifactAttached>
-                            <shadedClassifierName>with-common</shadedClassifierName>
+                            <outputFile>${project.build.directory}/${project.build.finalName}-with-common.jar</outputFile>
                             <artifactSet>
                                 <includes>
                                     <include>com.skyflow:common</include>