The comparison jar the contract gate builds was being published. shadedArtifactAttached
makes it a real project artifact, and Maven installs and deploys attached artifacts, so
a deploy to a throwaway repo showed exactly what would reach jfrog and Maven Central:
skyflow-flowvault-java-<v>.jar
skyflow-flowvault-java-<v>.pom
skyflow-flowvault-java-<v>-sources.jar
skyflow-flowvault-java-<v>-tests.jar
skyflow-flowvault-java-<v>-with-common.jar <- should never have shipped
Same for skyvault. It is a build input for japicmp, not something a consumer should be
able to resolve - and it duplicates the whole SDK plus common under a classifier, so
anyone who found it would get a second, silently divergent copy of the library.
Switched to shade's outputFile, which writes the jar to disk and attaches nothing, and
moved it out of the modules entirely: it now lands in the repo-root api-report/build/,
gitignored. Nothing under a module directory can package or publish what it cannot see.
The committed baselines move the same way, from <module>/api-report/ to the repo-root
api-report/. They were never packaged - api-report/ is not a resource directory, and
they appear zero times inside every built jar - but keeping the contract fixtures out of
the source trees makes that structural rather than something to re-verify each time.
Also set createDependencyReducedPom=false on this execution: it is a second shade run
whose only job is to produce a comparison file, and it has no business rewriting the pom
the module publishes.
Verified: a real deploy now publishes exactly the four expected artifacts per module and
no with-common; both contract gates pass reading the new paths; the snapshot script
regenerates from api-report/build/; common 158, flowvault 674 tests pass; YAML parses;
cspell clean. skyvault's 3 ConnectionClientTests failures are pre-existing and need the
real SKYFLOW_CREDENTIALS secret, which CI supplies.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The problem
The comparison jar the contract gate builds was being published.
shadedArtifactAttachedmakes it a real project artifact, and Maven installs anddeploys attached artifacts. A deploy to a throwaway local repo shows exactly what
would have reached jfrog and Maven Central:
Same for
skyvault. It is a build input for japicmp, not something a consumershould be able to resolve — and it contains the whole SDK plus
commonunder aclassifier, so anyone who found it would get a second, silently divergent copy of
the library.
This came in with #397, so it is live on the next release. Nothing has shipped with
it yet.
The fix
Two changes, so this cannot recur by accident:
1. Never attach it. Switched to shade's
outputFile, which writes the jar todisk and attaches nothing. No artifact, so nothing to install or deploy.
2. Move it out of the modules. It now lands in the repo-root
api-report/build/(gitignored). Nothing under a module directory can package or publish what it cannot
see — the guarantee is structural, not a setting someone has to remember.
The committed baselines move the same way,
<module>/api-report/→ repo-rootapi-report/. They were never packaged —api-report/is not a resource directory,and they appear zero times inside every built jar — but keeping the contract
fixtures out of the source trees makes that structural too.
Also set
createDependencyReducedPom=falseon this execution. It is a second shaderun whose only job is to produce a comparison file; it has no business rewriting the
pom the module publishes.
Verification
A real
mvn deployto a throwaway repo now publishes exactly this, per module:skyflow-java-2.1.1.jarskyflow-flowvault-java-<v>.jarskyflow-java-2.1.1.pomskyflow-flowvault-java-<v>.pomskyflow-java-2.1.1-sources.jarskyflow-flowvault-java-<v>-sources.jarskyflow-java-2.1.1-tests.jarskyflow-flowvault-java-<v>-tests.jarNo
with-common, andfind skyvault flowvault common -name "*with-common*"returnsnothing.
Also: both contract gates pass reading the new paths;
contract-snapshot-update.shregenerates from
api-report/build/; common 158 and flowvault 674 tests pass;YAML parses; cspell clean across 305 files.
skyvault's 3
ConnectionClientTestsfailures are pre-existing and unrelated — theyneed the real
SKYFLOW_CREDENTIALSsecret, which CI supplies.No source, README or release-workflow changes.