ci: let a build see a sibling repository's snapshot the day it is published

[marevol]

Two lines of configuration. This is what currently blocks codelibs/fess#3428, and it will block the six plugin repositories the moment core publishes a snapshot they need.

What happens today

These two repositories are how one repository in this family sees another's change, and Maven's default updatePolicy for a snapshot is daily. A build whose ~/.m2 already resolved a -SNAPSHOT earlier the same day never asks again — so a CI job that caches the local repository cannot see a sibling repository's snapshot published minutes ago.

Measured, not assumed

codelibs/fess-crawler#204 merged	02:48:54
its snapshot deployed	02:49:31
codelibs/fess#3428 re-run restored its cache	02:59:29
that run failed	03:03:24

The failure:

DiXmlParseFailureException: Failed to parse the dependency XML.
[Dependency XML] crawler/client.xml included by app.xml
Caused by: java.lang.NoClassDefFoundError: software/amazon/awssdk/auth/credentials/AwsCredentials

crawler/client.xml in the previous fess-crawler-lasta still declared s3Client, whose class needs the AWS SDK that #3428 removes, and LastaDi resolves a class attribute when it parses the XML. The published jar was already correct: downloading fess-crawler-lasta-15.9.0-20260910.024931-36.jar shows zero s3Client components and zero s3:.* registrations.

The job never looked. Searching the 2951-line log:

• Cache restored from key: Linux-maven-1184b2e..., 262 MB
• Downloading from codelibs.org.snapshot — 0 occurrences
• Downloading/Downloaded of any fess-crawler artifact — 0 occurrences

The workflow caches ~/.m2/repository with restore-keys: Linux-maven-, so a differing pom.xml hash still restores an older cache, and mvn is invoked without -U. Nothing in that combination can expire before the next day.

Reproduced and verified locally, on the same shape of cache

My ~/.m2 held the same stale jar — unzip -p .../fess-crawler-lasta-15.9.0-SNAPSHOT.jar crawler/client.xml counted 1 s3Client component.

After mvn install of this branch and a single mvn dependency:resolve in the Fess branch:

• the log shows Downloading from codelibs.org.snapshot: .../fess-crawler-lasta/15.9.0-SNAPSHOT/maven-metadata.xml, then Downloaded
• build 20260910.024931-36 appears in ~/.m2
• the resolved jar now counts 0 s3Client components, 0 s3:.* registrations, and names the plugin that took over

Then, using nothing but published artifacts plus the new plugin jar, a LastaDi container on a plain JVM built clientFactory and mapped s3://bucket/key to org.codelibs.fess.crawler.client.s3.S3Client, with file: unaffected — 9 checks, all passing. Without the plugin, which is what CI's "Run Fess" step does, the container still initialises. So #3428 was correct all along.

Why here rather than -U in one workflow

Every consumer inherits this pom. The plugin repositories' CI checks out codelibs/fess-parent, installs it from source, and then resolves org.codelibs.fess:fess from these repositories — so fess-sso-saml, fess-sso-spnego, fess-sso-entraid, fess-sso-oidc, fess-storage-s3 and fess-storage-gcs are all in the same window whenever core publishes. Fixing it in one workflow would leave six.

Cost

One metadata request per snapshot dependency per build — for Fess that is five artifacts. -o skips it entirely, and a release build has no snapshot dependencies to check. The comment in the pom records the incident so the setting is not later removed as noise.