One build product per library for jmsfx-creator and jmsfx-server

[ctgnz]

Split out of #102, which had grown to cover four separable pieces of work.

Neither application compiles against a symbology library any more — #76 for the creator, #93 for the server — so which one they ship with is purely a packaging decision. Today both hard-code jmsfx-standard as a runtime dependency, so there is exactly one build product and it is the standard one.

The plan is one instance per library on its own *.ctg.co.nz subdomain, which needs one distinct build product per library.

Shape

A Maven profile per library in each application, each producing an artifact distinguished by classifier — jmsfx-server-2.0.0-standard.jar, -hallux, -battleorder — rather than one artifact whose contents depend on how it was built. A jar you can identify from its filename matters once three of them are being shipped to three boxes.

No activeByDefault. A default-activated profile is switched off the moment any other profile is named on the command line, and #103 put mvn -Prelease deploy in the release workflow. A standard profile relying on default activation would silently deactivate during a release and publish an application with no library in it — and that failure is quiet and late: the jar starts, then answers 500 to every request with "No IconLibrary on the classpath". The library is named explicitly, and a build naming none should fail rather than guess.

Two packaging behaviours that differ, and why

Worth writing down, because the two applications legitimately need different dependency declarations:

• jmsfx-server must use runtime without optional. spring-boot:repackage leaves optional dependencies out of BOOT-INF/lib, so an optional library never reaches the fat jar. Found in Make jmsfx-server library-agnostic, with one concrete IconRestController #93.
• jmsfx-creator currently uses runtime + optional and works, because its bundle is assembled by dependency:copy-dependencies into target/lib, which does include optional dependencies — optional only stops a dependency reaching consumers.

Since nothing consumes either as a library — #109 removed the last case — optional earns nothing in either, and dropping it from the creator makes the two consistent and removes a trap for whoever next wonders why one has it.

Where the profiles live

In the jmsfx-viewer parent introduced by #102, since that is the level the deployables are produced at, rather than repeated in each application. That makes #102's restructure a prerequisite for this rather than a sibling.

Nine creator bundles, two classifiers each

Three platforms times three libraries. The release workflow's packaging matrix gains a library dimension, and each bundle is named for both — jmsfx-creator-<version>-<library>-<platform>.zip.

Worth being precise about "classifier" here: the jpackage bundles are not Maven artifacts. They are built by the workflow and attached to the GitHub release, so library and platform are a filename convention rather than two Maven classifiers, which an artifact cannot have. The jmsfx-server jar is a real Maven artifact and does take a single classifier naming its library.

The download page becomes library-aware

Today download.html is a generic link to the releases page plus a table telling the reader which filename to look for. Each server instance should instead offer Windows, macOS and Linux buttons pointing at the bundles for the library that instance is running - a visitor to a hallux subdomain should get the hallux creator without having to know that is what they want.

That needs the server to know two things about itself at runtime:

• which library it is running - An IconLibrary cannot say which library it is #111, which is therefore a prerequisite here rather than a nice-to-have;
• its own version, so a 2.0.0 server offers the 2.0.0 creator rather than whatever is newest. Spring Boot writes Implementation-Version into the manifest, so this is readable without anything generated.

With both, the button href is https://github.com/ctgnz/jmsfx/releases/download/<version>/jmsfx-creator-<version>-<library>-<platform>.<ext>.

The alternative - GitHub's releases/latest/download/<asset>, which resolves without knowing the version - only works if the asset name omits the version, and then a downloaded file cannot say which release it came from. Offering the matching version seems the better trade.

The notes the table carries are worth keeping: Apple Silicon only, what to run once unzipped, and the code signing warnings, which are not going away.

Related

#111 is what makes a deployment verifiable once this lands — today a running instance cannot say which library it has, and three subdomains running three libraries is exactly when that starts to matter.

Related: #102, #93, #76, #103, #111.