Ship the 3D field viewer's web content in the installers

[jcschaff]

Closes the packaging gap tracked in #1851. Stacked on #1829 — base is vtk/field-viewer, so the diff here is just the four files below; retarget to master once #1829 lands.

FieldViewerServer already serves the viewer page from <installDir>/webviewer, but nothing ever put content there. On an installed client the directory is absent, so "View in 3D" opens a page that cannot load. This ships it.

The three pieces

file	change
VCell.install4j	a webviewer mount point, a source-path variable, a dirEntry (3 lines)
Dockerfile-clientgen-dev	copy the content to /vcellclient/webviewer
CI-full.yml	fetch the wasm bundle before that image builds

site_deploy.yml needs no change — worth stating, because #1851 originally claimed otherwise. It stages nothing: it pulls the prebuilt vcell-clientgen image and runs build_installers.sh inside it, where mavenRootDir=/vcellclient refers to paths baked into the image. So everything an installer ships is COPYd in when CI-full builds clientgen.

Two things a reviewer should check

maven-jars is the wrong template, and it is the obvious one to reach for. Its mountPoint="719" is lib, not the install root. bionetgen is the right precedent: a rootless mount point, relative to the install root, which is what -Dvcell.installDir=${launcher:sys.launcherDirectory} resolves to and what staticRoot() looks under.

Why the fetch is in CI rather than the maven build. The localsolvers precedent argues for a download-maven-plugin execution, and that would work — but solvers are downloaded because developers actually run them locally, whereas this bundle is only needed to build an installer. Putting it in maven would impose a 12 MB download on every developer for a feature that is off by default. Developers who want the viewer locally already run the same script themselves.

Verified

Both claims in the Dockerfile comment were checked with real docker builds, not reasoned about:

• The copy produces exactly index.html, viewer.js, vendor/vtk.umd.js and assets/vtk-wasm/*.tar.gz — 12 MB, with the fetch script, package.json and README left behind.
• With assets/ absent (a skipped fetch), the build fails with "/webapp-viewer/assets": not found rather than silently producing an installer whose viewer 404s.

What this does not do, and the risk it adds

The feature stays behind vcell.fieldViewer.enabled, still defaulting to false, so this changes nothing a user sees. It does not pre-seed the flag in the install4j vmoptions templates; testers still add the line themselves.

The real cost is that the release build gains a network dependency: the bundle is fetched from the pinned virtualcell/vcell-vtk-wasm v1.0.0 release, and clientgen blocks release. If that release is unreachable, the release build fails. That is the argument for merging this early in a cycle rather than next to a release. It also adds ~12 MB to all five media, and the .tar.gz will not compress further under install4j's LZMA.

Note this cannot be fully exercised outside a real site_deploy run — the installer build needs the install4j license and both code-signing keystores.

🤖 Generated with Claude Code