mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-08-23 18:47:34 +02:00
Rsclub2_2andClaude Opus 5
f014b4697b
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)