Skip to content

Bring jmsfx-hallux into the jmsfx repository - #107

Merged
ctgnz merged 1 commit into
masterfrom
feat/106-jmsfx-hallux-module
Sep 25, 2026
Merged

ctgnz merged 1 commit into
masterfrom
feat/106-jmsfx-hallux-module

Conversation

@ctgnz

@ctgnz ctgnz commented Sep 25, 2026

Copy link
Copy Markdown
Owner

Closes #106. Targets feat/103-maven-central, since it builds on that branch's publishing configuration — retarget to master once #105 merges.

The hallux extension is a set of additions to APP-6E — icons edition E dropped, an enlarged Dismounted Individual set, extra amplifiers — and none of it is hallux's proprietary data. It sat in the hallux repository for historical reasons while the model it is generated from has always been here.

It also gives hallux a released version to pin. Its copy depended on jmsfx-core:1.5.0-SNAPSHOT and had to move with every change made here, because a snapshot means whatever is in the reactor right now.

Copied, not moved. hallux/jmsfx-hallux stays until 2.0.0 is released and hallux switches to the published artifact; deleting it first would leave hallux unbuildable in between. hallux's working tree is untouched.

The package rename

Now io.github.ctgnz.jmsfx.hallux, rather than the nz.co.ctg.hallux.jmsfx it carried from before jmsfx moved namespace. Source-incompatible for hallux, which is why it belongs in a major release and is cheaper now than once anything depends on the published artifact.

Worth knowing the name lives in two places: config-hallux.yml, and a config block at the head of model-hallux.yml. Changing only the first leaves half the generated files importing the old package — which is exactly what happened on the first attempt.

Three things the move brought with it

  • Both fragment trees are now under the build checks. FragmentNormaliser and FragmentShapeChecker were bound only to jmsfx-standard's, because the other tree sat in a repository with no dependency on this tooling — the reason recorded in jmsfx-generator/pom.xml, now updated. Both report clean: 577 free canvas fragments, 0 off the shape, 0 refused, twice.
  • Spotless had never been applied. hallux stages it but does not enforce it, so 155 generated files had never been formatted to the profile this build fails on.
  • A test that asserted nothing. ImageFileTest walked every element checking its fragment resolved and printed to stdout rather than failing — it could not fail. Deleted rather than ported.

Verification

Regenerating into the new location produced output byte-identical to hallux's copy — that is what says the move itself changed nothing. The package rename came after that, and was verified by checking no nz.co.ctg reference survives except foxglove's own package in HalluxIconLibrary.

mvn verify green across all eight modules.

Publishing

jmsfx-hallux goes to Central alongside jmsfx-core and jmsfx-standard, and needs nothing added — being a consumable library rather than an application, it is simply absent from the publishing plugin's exclusion list.

#102 no longer needs a separate jmsfx-hallux repository; I'll update that issue.

🤖 Generated with Claude Code

The hallux extension is a set of additions to APP-6E - icons edition E dropped,
an enlarged Dismounted Individual set, extra amplifiers - and none of it is
hallux's proprietary data. It was only in the hallux repository for historical
reasons, while the model it is generated from has always been here, and it
belongs with the other generated library.

It also gives hallux something it has never had: a released version to pin. Its
copy depended on jmsfx-core:1.5.0-SNAPSHOT and had to move with every change made
here, because a snapshot means whatever is in the reactor right now.

Copied, not moved. hallux/jmsfx-hallux stays until 2.0.0 is released and hallux
switches to the published artifact; deleting it first would leave hallux
unbuildable in between.

The package is io.github.ctgnz.jmsfx.hallux rather than the nz.co.ctg.hallux.jmsfx
it carried from before jmsfx moved namespace. That is a source-incompatible change
for hallux, which is why it belongs in a major release, and it is cheaper to make
now than once anything depends on the published artifact. The name lives in two
places - config-hallux.yml and a config block at the head of model-hallux.yml -
and changing only the first leaves half the generated files importing the old one.

Three things the move brought with it:

- Both fragment trees are now under the build checks. FragmentNormaliser and
  FragmentShapeChecker were bound only to jmsfx-standard's, because the other tree
  sat in a repository with no dependency on this tooling. Both report clean.
- The generated code needed Spotless applying. hallux stages Spotless but does not
  enforce it, so 155 files had never been formatted to the profile this build
  fails on.
- A test came across that asserted nothing - it walked every element checking its
  fragment resolved, and printed to stdout rather than failing. Deleted rather
  than ported.

Regenerating into the new location first produced output byte-identical to
hallux's copy, which is what says the move itself changed nothing; the package
rename came after that.

jmsfx-hallux publishes to Central alongside jmsfx-core and jmsfx-standard. It
needs nothing in the publishing configuration - being a consumable library rather
than an application, it is simply absent from the exclusion list.

Closes #106

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ctgnz
ctgnz changed the base branch from feat/103-maven-central to master September 25, 2026 22:21
@ctgnz
ctgnz merged commit db10a56 into master Sep 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bring jmsfx-hallux into the jmsfx repository

1 participant