feat(fess): install the plugins 15.9 unbundled, with bin/fess-setup

[marevol]

Fess 15.9 moved the Groovy script engine, the S3 and GCS storage backends and the four SSO authenticators out of the war. Each is a plugin now, so an image built from a 15.9 distribution alone quietly loses behaviour the 15.8 images had. The three snapshot images install all seven at build time.

What stops working without it	Plugin
script_type=groovy — and any data store, job or crawler script that leaves script_type unset, which still resolves to groovy	fess-script-groovy
s3: crawling and the S3 storage backend	fess-storage-s3
gcs: crawling and the GCS storage backend	fess-storage-gcs
sso.type=saml / spnego / entraid (and the legacy aad) / oic	fess-sso-saml / -spnego / -entraid / -oidc

oic is the one place the plugin name and the value differ, so the README table spells it out rather than leaving a reader to install fess-sso-oic.

Why bin/fess-setup rather than more curl in run.sh

run.sh already resolves a snapshot by hand — fetch maven-metadata.xml, scrape <timestamp> and <buildNumber>, rebuild the file name. bin/fess-setup install plugin does that, picks the version that fits the build, verifies the published SHA-1, and exits 1 when a plugin cannot be resolved. That last part is the reason it belongs in a RUN: a missing plugin fails the build instead of producing an image that is short a feature with nothing but an ERROR line in the boot log to say so. The seven jars add 36,392,732 bytes.

Verified by building all three variants

docker build on each of snapshot, snapshot-noble and snapshot-al2023, with the post-codelibs/fess#3429 fess-setup.jar standing in for the one today's published snapshot still carries. Each image ends with seven jars in app/WEB-INF/plugin under their timestamped Maven names, owned fess:fess, and fess-setup list installed sees all seven. install plugin fess-sso-nosuchthing exits 1, which is the claim the comment makes.

One thing that had to be checked rather than assumed: bin/fess-setup resolves java through $JAVA_HOME/bin/java and falls back to which. amazoncorretto:21-al2023 ships no which — but it does set JAVA_HOME, as do both temurin bases, so the fallback is never reached in any of the three.

run.sh was rejecting the new names

FESS_PLUGINS accepts a fixed set of artifact prefixes, and fess-sso- and fess-storage- were not among them, so FESS_PLUGINS=fess-sso-saml:15.9.0 was reported as unrecognized and skipped. Both are added.

fess-thumbnail- is added with them. It was already missing before 15.9 — fess-thumbnail-playwright is published and was being rejected — so it is not part of the 15.9 change; drop it from this PR if you would rather it went separately. The prefix list, the error message it prints and the README table all have to agree, which is why all three move together.

Before merging

1. build: ship bin/fess-setup in the rpm and the deb, not only the zip fess#3431, which ships bin/fess-setup in the rpm and the deb. Today it is in the zip only: the jdeb bin data set and the rpm bin mapping each list exactly fess, fess.in.sh and generate-thumbnail, confirmed against the built packages. The Alpine image installs from the zip and is unaffected; snapshot-noble and snapshot-al2023 cannot call fess-setup until that lands.
2. A Fess snapshot built after feat(setup): install plugins from the snapshot repository and GitHub releases fess#3429, which is what taught fess-setup to read the snapshot repository. The jar in the currently published snapshot predates it.
3. A Fess snapshot built after refactor!: move the SSO authenticators to fess-sso-* plugins fess#3430, which is merged (105e876d2) but not yet in a published snapshot — the newest is the 03:04Z build. Installing an SSO plugin into a war that still declares the same authenticator registers it twice. I compared the component names in that published war against the plugin jars: the four *Authenticator names collide, and so do s3StorageClient and s3_compatStorageClient (#3428 fixed those, so the same next snapshot clears them). fess-script-groovy and fess-storage-gcs collide with nothing and would be safe even against today's build.

All three come down to the same thing: build these images from the next published Fess snapshot, not the current one.

Not included

compose/playwright/ is pinned to 15.8.0-noble and unaffected, but it will need bin/fess-setup install nodejs when it moves to 15.9: driver-bundle-1.60.0.jar, the 216 MB of Node.js binaries Playwright's bundle carried, is gone from the distribution while fess-crawler-playwright itself is still in the war. Baking Node.js into every image would undo the size decision that removed it, so it belongs in that image, not these.

When 15.9.0 releases and fess/15.9* is created from these files, the plugin step comes with it and needs no change — fess-setup will resolve releases instead of snapshots on its own.