fix(manifest): keep the Maven extension build out of the developer's home directory

[John-David Dalton (jdalton)]

Building the Coana Maven extension writes into your own home directory. build-jar.sh calls the bundled Maven wrapper with no repository override, so every run drops the plugin and dependency closure into ~/.m2/repository and the wrapper's own downloaded Maven distribution into ~/.m2/wrapper/dists. Run the script once and your personal Maven cache now holds artifacts you never asked for.

The bigger problem is reproducibility, not tidiness. When a build reads and writes a cache that lives in your home directory, it can quietly succeed because of something an unrelated project downloaded months ago. The same build on a clean machine, or in CI, does not have that cache and can fail for reasons nobody can reproduce locally.

This change points the build at a directory under the OS temp dir instead, so it stops touching your home Maven tree and always resolves from a cache it owns.

The change — two overrides, because Maven splits the work between two programs

Setting one override alone leaves the other half still writing to the home directory:

Override	What it moves	Which program reads it
-Dmaven.repo.local	the downloaded artifacts (the local repository)	the mvn binary
MAVEN_USER_HOME	the wrapper's own Maven distribution	the mvnw shell script, not mvn

Both now point inside a single directory under the OS temp root, and the Maven invocation runs in a subshell so the environment change does not leak into the rest of the script.

Why a stable path and not a fresh one each run — a cold cache every time would make the build slow and network-dependent

A brand new temp directory per run is the most isolated option, but it throws away the cache every time. The extension build needs a full plugin closure, so every invocation would re-download it and the build would become slow and dependent on the network being up.

A stable path under the temp dir keeps the isolation while letting the cache stay warm between runs. Anyone who genuinely wants a cold build can set SOCKET_CLI_MAVEN_HOME to somewhere else.

How this was verified — Maven's behaviour was measured before and after, not assumed

Maven's behaviour was checked directly before and after, by recording a timestamp and then listing files newer than it.

Confirming the leak is real, using a dependency version that was not already cached:

• Before the run, the version was absent from the local repository.
• After a run with no override, the jar, pom and checksums were present in the local repository, along with newly written parent and BOM metadata.

Confirming the overrides work:

• With -Dmaven.repo.local pointed at a temp directory, that directory received the full closure and the local repository under the home directory received zero new files.
• MAVEN_USER_HOME on its own does not move the artifact repository. The mvn binary ignores it, and the directory is never even created. It only moves the wrapper distribution, which is why the fix sets both.
• With MAVEN_USER_HOME pointed at a temp directory, the requested Maven distribution was unpacked there and the wrapper directory under the home directory was unchanged.

Confirming the patched script end to end:

• build-jar.sh ran to completion and produced coana-maven-extension.jar.
• The temp directory held the artifact repository and the wrapper distribution.
• Zero new files appeared anywhere under the home Maven directory.

Scope — only the extension build; the JVM test fixtures are a separate PR

Only build-jar.sh changes. The Maven, Gradle and sbt compatibility fixtures under scripts/test/ have the same class of problem and are being handled separately; they are untouched here.

---

Note

Low Risk
Build-script-only change for the CLI Maven extension jar; no runtime manifest or auth paths are touched.

Overview
build-jar.sh no longer lets the bundled mvnw populate the developer’s ~/.m2. The Maven invocation runs in a subshell with MAVEN_USER_HOME and -Dmaven.repo.local both aimed at a stable directory under the OS temp root (default socket-cli-maven-home), so wrapper distributions and dependency/plugin caches stay out of the home Maven tree while remaining warm across runs.

SOCKET_CLI_MAVEN_HOME overrides that base path when someone wants a cold or custom cache location. The jar copy step and output path are unchanged.

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

[cursor]

Cursor Bugbot has reviewed your changes using high 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 2e7512b. Configure here.}

[cursor]

Relative cache path cwd mismatch

Medium Severity

When SOCKET_CLI_MAVEN_HOME or TMPDIR is a relative path, mkdir -p uses the caller’s working directory, but MAVEN_USER_HOME and -Dmaven.repo.local are applied after cd into the extension directory, so Maven and the wrapper write to a different tree than the one created upfront.

 

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