Package and attach every library the release publishes - #146
Merged
Merged
Conversation
Found while the 2.0.0 tag's first run was failing. All four are cases of the workflow describing a repository that has moved on. jmsfx-battleorder gets platform bundles. The matrix comment said it plainly - "jmsfx-battleorder makes it nine once jmsfx#81 can generate it - one word on the line below" - and #81 closed long ago, with #82 settling how a library gets its fragments. Two libraries by three platforms becomes three by three. Verified the new job's build: a clean `-Pbattleorder -pl :jmsfx-creator -am package` puts exactly jmsfx-battleorder and jmsfx-core in the dependency directory, which is what it must be - two IconLibrary implementations on one classpath is the case discovery has to fail on (#76). The archive name already carries the library, so nine bundles do not collide. The GitHub Release attaches all four library jars rather than jmsfx-core and jmsfx-standard alone, and names them rather than globbing `*.jar`. This step runs after the publish, so -Prelease has already built sources, javadoc and jmsfx-core's test jar into those same directories - and those belong on Central, where a build resolves them, not attached to a release as well. The header described a workflow that stopped existing at #103: "jmsfx isn't published to Maven Central yet ... add a deploy step matching foxglove's". The deploy step is there. It now says what a tag does, and records the four secrets it needs - because the first 2.0.0 run failed with "gpg: no default secret key", the workflow having been copied from foxglove while the secrets were never created here. And the aggregator's exclusion claimed "jmsfx:1.5.0 and earlier stay on Central as the parents they were". Nothing of jmsfx is on Central: io.github.ctgnz holds only foxglove, and nz/co/ctg does not exist. 2.0.0 is the first jmsfx release to reach it. The exclusion is still right - the aggregator's only content is a module list and nothing resolves it - but not for that reason. Co-Authored-By: Claude Opus 5 <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
1 participant
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.
Part of #144. Found while the 2.0.0 tag's first run was failing, and wanted before the tag is redone.
All four are the workflow describing a repository that has moved on.
jmsfx-battleorder gets platform bundles
The matrix comment said it outright — "jmsfx-battleorder makes it nine once jmsfx#81 can generate it — one word on the line below". #81 closed long ago and #82 settled how a library gets its fragments, but the matrix still listed two libraries. Three by three platforms, nine jobs.
Verified the new job rather than assuming it: a clean
-Pbattleorder -pl :jmsfx-creator -am packageputs exactlyjmsfx-battleorderandjmsfx-corein the dependency directory. That is the thing to check, because twoIconLibraryimplementations on one classpath is the case discovery must fail on (#76). The archive name already carries${{ matrix.library }}, so nine bundles do not collide.The release attaches all four library jars
Was
jmsfx-coreandjmsfx-standardonly. Now all four, and named rather than globbed — this step runs after the publish, so-Preleasehas already built sources, javadoc and jmsfx-core's test jar into those directories, and*.jarswept them in. Those belong on Central where a build resolves them, not duplicated as release assets.Two comments that were wrong
The header described a workflow that stopped existing at #103 — "jmsfx isn't published to Maven Central yet … add a deploy step matching foxglove's". The deploy step is there. It now says what a tag actually does, and records the four secrets it needs, since the first 2.0.0 run failed on
gpg: no default secret key: the workflow was copied from foxglove and the secrets were never created here.The aggregator's exclusion claimed "jmsfx:1.5.0 and earlier stay on Central as the parents they were". Nothing of jmsfx is on Central —
io.github.ctgnzholds onlyfoxglove, andnz/co/ctg404s. 2.0.0 is the first jmsfx release to reach it. The exclusion is still correct, just not for that reason.After this merges
The
2.0.0tag needs moving to the new HEAD, since a re-run executes the workflow as it exists at the tagged commit — which is why this could not simply follow the publish.🤖 Generated with Claude Code