test(manifest): resolve the JVM compat fixtures' deps from generated stub artifacts

[John-David Dalton (jdalton)]

The JVM compat test fixtures pull three real, published artifacts down from Maven Central purely so the dependency graph has the right shape — one external production dependency, one test-scope dependency, and one transitive of that test dependency. No fixture code ever imports them. They are never compiled against and never executed. They are stage props.

Stage props still get CVEs. One of them, commons-io:commons-io:2.11.0, fell into the range of GHSA-78wr-2p64-hpwj, Dependabot opened #1449, and #1457 / #1458 are open right now purely to move a version number in a test fixture. That will happen again with the next advisory against whatever the fixtures happen to pin. This PR replaces those three artifacts with stubs generated at test time, so no advisory can ever touch them again.

The second thing it fixes: running these suites used to write into your own ~/.m2, ~/.gradle and ~/.ivy2. That is untidy, but the real cost is that a run could pass because an artifact happened to already be warm in your home cache — so a genuine resolution regression could hide on your machine and only appear in CI. Each tool is now pointed at one shared cache root instead.

Builds on #1457 (fix/commons-io-cve), so the version-agnostic assertions that PR introduced are inherited rather than fought with. Merge that one first.

The problem — three real artifacts pulled in for their shape, not their code

The Maven smoke fixture declared commons-io:commons-io, junit:junit, and junit's transitive org.hamcrest:hamcrest-core. It needed them only for their shape: one external prod dependency, one test-scope dependency, and one transitive of that test dependency.

No fixture code imports any of them. App.java calls Lib.greet() and nothing else, so they are never compiled against and never executed.

They still cost real work. commons-io 2.11.0 fell into the range of GHSA-78wr-2p64-hpwj, Dependabot opened #1449, and #1457 / #1458 exist just to move a number.

The fix — a pattern gradle-compat has always used, moved up one directory so all three fixtures share it

gradle-compat has never had this problem. Its make-localrepo.sh generates a tiny file-based Maven repository of stub artifacts — a generated .pom plus an empty-but-valid .jar — at test time, and the Gradle fixture resolves demo.lib:foo and demo.test:bar from it. Nothing binary is committed and no advisory can ever touch it. maven-compat was the odd one out, not the place to invent something new.

So the generator moves up one directory to test/make-stub-repo.sh, next to run-compat.sh, and all three fixtures share it. It takes an output directory and a list of coordinates. The one new capability is that a stub can declare a dependency on another stub, which is what Maven needs for the transitive shape:

bash "$HERE/../make-stub-repo.sh" "$STUBS" \
  'demo.ext:tool:1.0' \
  'demo.ext:harness:1.0+demo.ext:harness-core:1.0' \
  'demo.ext:harness-core:1.0'

maven-compat now declares these instead:

Stub coordinate	Role it plays in the fixture	Was
demo.ext:tool	external prod dependency	commons-io:commons-io
demo.ext:harness	test-scope dependency	junit:junit
demo.ext:harness-core	transitive of the test-scope dependency	org.hamcrest:hamcrest-core

sbt-compat had the same exposure — it still pinned the vulnerable commons-io:commons-io:2.11.0, invisible to Dependabot only because Dependabot does not read build.sbt — so it moves to the same stubs.

How resolution is wired — one repository property on the root pom, overridden by the script

The root pom declares one repository whose URL comes from a property, and smoke-test.sh passes the absolute path of the repo it just generated:

<repository>
  <id>socket-stubs</id>
  <url>${stub.repo.url}</url>
  ...
</repository>

Child modules inherit it, which is verified below. The property has a default of file://${maven.multiModuleProjectDirectory}/localrepo so a bare mvn compile inside project/ also works; -Dstub.repo.url from the script overrides it.

Alternative considered and rejected: seeding the artifacts straight into the run's local repository. That has to know the local repo path, which breaks the moment anyone passes -Dmaven.repo.local — including the empty-local-repo check below.

The generated repos are gitignored and rebuilt from scratch on every run, like records.tsv.

The caches — one shared root, stable so the tool closure stays warm, stubs evicted every run

The suites no longer touch your own caches. compat-cache.sh resolves a single cache root and each tool is pointed at it:

${SOCKET_COMPAT_CACHE:-${TMPDIR:-/tmp}/socket-manifest-compat}

Tool	How it is redirected	State before this PR
Maven	-Dmaven.repo.local	wrote to ~/.m2
Gradle	-g	already isolated, but at a directory inside the repo tree
sbt	-Dsbt.ivy.home and COURSIER_CACHE	global base was already a mktemp -d; the Ivy home and coursier cache were not covered

SOCKET_COMPAT_CACHE already existed in run-compat.sh for the downloaded build-tool distributions, so this reuses it rather than inventing a second knob; run-compat.sh now reads it from the shared file too.

The most important reason is reproducibility, not tidiness — a run used to be able to pass off a warm home cache. Two lesser reasons: records.tsv embeds the resolved artifact path, so it used to contain a path under the developer's home directory, and a test should not write into a developer's real Maven cache.

Trade-off: a stable root, not a fresh one per run. A mktemp -d every time would be maximally hermetic, but it would re-download Maven's whole plugin closure on every invocation, making the suite slower and more network-dependent than it is today. So the root is stable and each tool's own closure is cached across runs — while the stub artifacts are evicted from it before every run, so the thing actually under test is always resolved from scratch. That keeps the fresh-resolution property exactly where it matters. Set SOCKET_COMPAT_CACHE to a fresh mktemp -d when you want a completely cold run.

The first run after the cache root is cleared pays for the tool's closure download. Measured here: about 70 seconds cold, about 35 warm.

Coverage is not weakened — the same assertions, and one that gets stronger

The assertions prove exactly what they proved before: external prod dep in a prod root with a materialized jar, test-scope dep and its transitive kept out of prod roots, internal reactor module demo:lib emitted by its bare id and marked direct, and -Dsocket.populateFilesFor materializing only the in-scope artifact. Matching is still on groupId:artifactId with the version ignored, and the scoped run still derives its GAV from the emitted records, so no version is written anywhere in the test.

One assertion gets stronger. The transitive check used to be conditional (if hamcrest and in_prod(hamcrest)), tolerating hamcrest being absent because that depended on which junit version resolved. With a stub graph the transitive is deterministic, so its absence is now a failure.

What this does not claim — the fixture is still not offline, and commons-io still lands in the local repo

This is not a fully offline fixture, and the change does not make it one. Maven fetches its own plugins from Central to run at all, and those plugins have their own dependencies. maven-resources-plugin:3.3.1 depends on commons-io:commons-io:2.11.0 — the very version this whole thread is about — so commons-io still lands in the local repository during a run.

It is not in our dependency graph, we do not declare it, and Dependabot does not alert on it. What this PR removes is our declared externals, not Maven's build closure.

What I checked — Maven 3.9.10 and Gradle 8.14 end to end; sbt is reasoned, not run

Maven 3.9.10, Gradle 8.14, JDK 21.0.3 on macOS.

Ran — the Maven smoke test end to end. The brief assumed it could not run, because it needs the Coana extension jar as its second argument — but maven-extension/build-jar.sh builds that jar from this repo, so it was buildable locally. Both phases pass:

+ Apache Maven 3.9.10
PASS: tool=maven; demo.ext:tool:jar:1.0 prod+jar; harness/harness-core dev; internal demo:lib (bare id, direct)
PASS (populateFilesFor scoping): demo.ext:tool materialized, demo.ext:harness skipped

Ran — the same thing again with an empty local repository (MAVEN_ARGS=-Dmaven.repo.local=$(mktemp -d)), still exit 0. Counting where every artifact in that repository came from afterwards:

• 6 files from socket-stubs — the three stubs' poms and jars, including both test-scope jars materialized under --with-files
• 71 files from central — Maven's own plugin closure
• commons-io present at exactly one version, 2.11.0, _remote.repositories says central=, pulled by maven-resources-plugin-3.3.1.pom
• org/junit/junit-bom poms present, also central=, also plugin closure
• no junit:junit and no hamcrest anywhere

mvn --batch-mode -Dmaven.repo.local=$(mktemp -d) dependency:tree confirms the shape and that the child module inherited the repository:

demo:app:jar:1.0
+- demo:lib:jar:1.0:compile
+- demo.ext:tool:jar:1.0:compile
\- demo.ext:harness:jar:1.0:test
   \- demo.ext:harness-core:jar:1.0:test

Ran — cache isolation, verified rather than assumed. With the cache root pointed at a scratch path, the Maven smoke test passes both phases and the Gradle smoke test passes both phases. Full recursive listings of the real ~/.m2 and ~/.gradle hash identically before and after those runs. Neither suite's records.tsv contains any path under the home directory; the Maven file record now points into the isolated repository and the Gradle one points straight at the stub repo.

Ran — an A/B on the stub eviction. Leaving the previous run's stub copy in the local repository and then deleting the generated stub repo, mvn compile still succeeds — that is precisely the masking this guards against. Doing what the script does, evicting the stubs first, the same run fails with Could not find artifact demo.ext:tool:jar:1.0. So a broken stub repo cannot be hidden by a warm cache.

The assertion blocks needed no changes for any of this; they key on the .jar suffix, not on any path.

Ran — Gradle is not regressed. gradle-compat/smoke-test.sh runs end to end on Gradle 8.14 and passes both phases. The repo the shared generator produces for the Gradle coordinates is byte-identical to the old script's: same paths, same pom bytes, jars differing only in zip timestamps.

Ran — the assertion blocks against synthetic records.tsv input, extracted from the committed script rather than a copy. 16 cases, all behaving as expected: well-formed records pass; the prod stub missing, its jar not materialized, the test-scope dep in a prod root, the transitive in a prod root, the transitive missing, demo:lib absent or not direct or dev-only, two versions of the same coordinate, and both scoped-run defects all fail with the right message. The sbt block got the same treatment on 4 cases.

Ran — bash -n and shellcheck, clean on all four scripts.

Could not verify — the older matrix rows. The compat matrix covers Maven 3.6.3 / 3.8.8 / 3.9.9 and Gradle 1.12 through 9.2.1; only Maven 3.9.10 and Gradle 8.14 are installed here, so the older rows are unverified.

Did not run — sbt at all. sbt is not installed here and there is no CI for this matrix, so the sbt fixture changes are reasoned, not run — both the stub coordinates and the -Dsbt.ivy.home / COURSIER_CACHE relocation. The reasoning: "Socket Stubs" at s"file://.../localrepo" is a MavenRepository, which coursier supports natively on sbt 1.x and Ivy resolves through IBiblioResolver on 0.13. That form was chosen over Resolver.file(...)(Resolver.mavenStylePatterns) precisely because the pattern-based form is the one with known coursier sharp edges. If you would rather not carry an unrun change, the sbt hunk is easy to split out.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit aa0a2ed. Configure here.}

[cursor]

Weakened reactor bare-id check

Medium Severity

lib = coord('demo:lib:') no longer enforces a bare reactor id. The prefix also matches typed forms like demo:lib:jar:…, so a regression that stops emitting the bare groupId:artifactId:version id can still pass while the error text and pass line claim bare-id coverage.

Additional Locations (1)

• packages/cli/src/commands/manifest/scripts/test/maven-compat/smoke-test.sh#L84-L85

 

^{Reviewed by Cursor Bugbot for commit aa0a2ed. Configure here.}