Publish snapshots via Maven's timestamped unique-snapshot protocol - #90
Merged
Conversation
Sonatype central only registers the FIRST plain PUT of a non-unique snapshot filename; the repo's maven-metadata.xml keeps pointing at that build, so republishing a -SNAPSHOT version is accepted but never served. scripts/upload-snapshots.py (ported from tacita) uploads timestamped filenames and re-PUTs each module's maven-metadata.xml with an incremented buildNumber, matching what mvn/gradle do when deploying a snapshot remotely. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xg5JMK3qu2NPT6qKtDj5H6
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Sonatype central's maven-snapshots repo only registers the FIRST plain PUT of a non-unique snapshot filename (
foo-1.0-SNAPSHOT.jar): later republishes of the same-SNAPSHOTversion are accepted (200,last-modifiedeven updates) but never served — the repo'smaven-metadata.xmlkeeps pointing at the first build forever. This bit tacita on episode6/tacita#20, where every republish of0.0.4-SNAPSHOTkept serving the version's original pre-PR bytes, breaking consumers' CI with unresolved references. This repo's publish workflow used the same plain-PUT loop, so it carries the same latent bug.Changes
scripts/upload-snapshots.py(ported verbatim from tacita): publishes snapshots via Maven's timestamped unique-snapshot protocol — timestamped filenames (foo-1.0-<timestamp>-<build>.jar) plus a regenerated per-modulemaven-metadata.xmlwith an incrementedbuildNumber, which is whatmvn/gradledo natively when deploying snapshots remotely and what central requires for a snapshot overwrite to actually be served.publish-artifacts.yml: the snapshot branch of the publish step calls the script instead of the curl PUT loop. The release path (bundle POST to the publisher API) is unchanged.Validation
javap).publish-snapshotlabel, so its Publish Artifacts run publishes2.0.0-alpha04-SNAPSHOTthrough the new path end-to-end.🤖 Generated with Claude Code
https://claude.ai/code/session_01Xg5JMK3qu2NPT6qKtDj5H6