Document the coordinate JitPack actually serves - #7
Merged
Conversation
Verified against JitPack with a throwaway snapshot build of master rather
than by burning the 2.0.0 tag on a guess. Two things came out of it.
The build itself is fine: master built ok on JitPack's openjdk17 image and
registered both modules, so jitpack.yml, the JDK choice and dropping the
pinned daemon JVM all hold up on their infrastructure.
The coordinates in the docs did not hold up. A repository publishing more
than one artifact is addressed as com.github.<user>.<repo>:<module>, so the
group carries a dot before the repository name:
com.github.rayzone107.SegmentedProgressBar:segmentedprogressbar:2.0.0
com.github.rayzone107.SegmentedProgressBar:segmentedprogressbar-compose:2.0.0
The flat form the README documented works for the View artifact only, and by
coincidence: JitPack reads the artifact id as a repository name, and this
repository happens to be called that. Nothing is named
segmentedprogressbar-compose, so that request comes back 401 while the
dotted one returns 200. Documenting the dotted group for both keeps them
consistent.
Nothing in the build needs to change, because JitPack rewrites the published
POM's group and version itself, including the Compose artifact's dependency
on the base one.
While checking the history: the tags on this repository are 1.00, 1.01 and
tag_v1, not 0.0.1, which was only ever the version string inside the build.
None of them resolve today either, since JitPack rebuilds on request and the
2018 build cannot run on current infrastructure. docs/MIGRATION.md now says
so rather than implying an upgrade path that was never working.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Verified against JitPack with a throwaway snapshot build of master rather than by burning the 2.0.0 tag on a guess. Two things came out of it.
The build itself is fine: master built ok on JitPack's openjdk17 image and registered both modules, so jitpack.yml, the JDK choice and dropping the pinned daemon JVM all hold up on their infrastructure.
The coordinates in the docs did not hold up. A repository publishing more than one artifact is addressed as com.github..:, so the group carries a dot before the repository name:
The flat form the README documented works for the View artifact only, and by coincidence: JitPack reads the artifact id as a repository name, and this repository happens to be called that. Nothing is named segmentedprogressbar-compose, so that request comes back 401 while the dotted one returns 200. Documenting the dotted group for both keeps them consistent.
Nothing in the build needs to change, because JitPack rewrites the published POM's group and version itself, including the Compose artifact's dependency on the base one.
While checking the history: the tags on this repository are 1.00, 1.01 and tag_v1, not 0.0.1, which was only ever the version string inside the build. None of them resolve today either, since JitPack rebuilds on request and the 2018 build cannot run on current infrastructure. docs/MIGRATION.md now says so rather than implying an upgrade path that was never working.