classes already runs the generator, so an orphan key, a dropped placeholder
or a duplicate fails the compile job with the generator's own message naming
the file -- verified by breaking strings_de.properties on purpose.
A step summary counts each language against the base, so the author of a
translation PR sees what they covered without reading the build log.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
What the removal left open (4 commits).
Compose's MenuBar is a javax.swing.JMenuBar set on the window, so Swing draws
it and no theme reaches it; with no look-and-feel configured that meant the
default Metal menu above a themed window. The bar is drawn in the window now,
except on macOS, where the system bar is where that platform expects it. Two
renderers read one description -- mainMenuModel is a plain function of the
state, which also gives the menus their first tests. Closing the main window
quits the application again, and the window writes its size back to the
profile; both had quietly stopped working when the last JavaFX stage went.
Then Etappe 7. Four faults shipped in the settings-window branch alongside a
green suite of 382 tests, because not one of those tests drew anything: a
control that never redrew, a tab strip that clipped mid-word, a form taller
than its window with no way down, and colours that came from Material rather
than the stylesheet. One regression test per class, and the spec's acceptance
criterion is met rather than assumed -- each fault was put back deliberately
and the matching test watched to fail.
The CI had never run the suite at all; it does now, headless. What that took
was not Xvfb: skiko's native library links against libGL and only has to be
loadable, since the drawing tests render in software. Without the package the
whole Compose half of the suite dies with a message that reads like a missing
display. Found by running the job under act rather than on GitHub.
The six tests that open a real window skip headless by their own guard. The
summary step counts from the result XML and fails on failures there, because
this project's rule is never to infer a green suite from an exit code.
Etappen 1 and 2 of the Compose migration (43 commits).
The Maven build, the single source tree and the JPMS module-info went together.
core now holds the domain and app-desktop the user interface, both built by
Gradle, packaged through jpackage from Gradle, with SpotBugs and PMD wired in.
JavaFX moves to the classpath, which is why the launcher is Main and not the
Application subclass. The PR check, the nightly artifacts, the release and the
AUR packages all build from Gradle; the macOS DMG points at its output.
Verified on Linux, macOS and Windows.
core then loses JavaFX entirely. It observes through kst4contest.observe --
ObservableValue, ObservableRoster, and UiDispatcher as the one boundary a
worker thread crosses to touch the interface. The controller collections become
rosters and the visible station list a pure derivation rather than a
FilteredList/SortedList chain, which is also what fixed two focus defects only
a load test had exposed: the keyboard focus stays where the operator put it,
and the send field keeps it after a row click.
The rule that outlives this commit: ObservableRoster is the store and the list
a view is bound to is a mirror of it, never the other way round.
The jdk.net incident was caused by duplication rather than by a single
oversight: the module list existed in module-info.java, in the jpackage Maven
plugin and in fourteen hardcoded --add-modules arguments across the workflows
and AUR PKGBUILDs. Only the path that CI does not use was kept up to date, so
every packaged build shipped a runtime image without jdk.net.
Add packaging/AddModules.java, a single file source program that reads the
requires clauses and prints the platform modules. It runs identically on the
Linux, macOS and Windows runners without a build step, and skips third party
requires such as jlayer, which is an automatic module and cannot be linked
into a runtime image at all, as well as test only requires and requires
static. All sixteen packaging call sites now resolve the list through it, so
they can no longer drift from the descriptor.
The jpackage Maven plugin takes its modules as individual XML elements and
cannot consume a generated value, so it remains a second copy. To keep it
honest the helper has a pom verification mode, bound to the validate phase
via exec-maven-plugin. Binding it to the build rather than to a workflow
trigger means it also fires on direct pushes to main, on tagged releases, in
both AUR PKGBUILDs and on local builds, none of which run the pull request
check.
The released AUR PKGBUILD builds from a tag tarball that may predate the
helper, and aur-publish.yml rewrites pkgver to the latest release, so it
falls back to the list carried in that tarball's own pom.xml.
Verified that the generated list produces a byte identical runtime image to
the previous hardcoded one, that removing a requires fails the build with a
precise diff, and that the pull request check and the push triggered nightly
AppImage job both succeed under act.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Generated-By: Claude Code (Claude Opus 5)
* Fixup WinTest Error
* Prepare CI/CD Auto Release Pipeline
* Fix CI/CD Components not running
* CI/CD Pre-Check n nighty and produce zip for more intutive User Design
* fix Version
* App Version Update.
* More Similar Naming to old Convention
Rsclub2_2andClaude Opus 5