build(deps): vendor json-smart from .m2 to isolate the build from scijava

[jcschaff]

Opening this on @danv61's dan-json-smart branch (commit 34f6739985, "Fixing a github cache problem") so the branch has a visible home and a place to record what we found, rather than being deleted silently.

The branch vendors net.minidev:json-smart:2.4.11 into lib/maven-repo, aiming to isolate the build from the maven.scijava.org outage that broke run 33104159035.

That outage is now fixed a different way in #2037. See the comment below for what the investigation turned up — including a .gitignore trap that is worth knowing about regardless of what happens to this branch.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx

[jcschaff]

Closing in favour of #2037, which fixes the same outage. Recording the details here because two of them are worth knowing independently of this branch.

1. There's a .gitignore trap, and it ate the jar

The vendored directory on this branch has no json-smart-2.4.11.jar in it — just the pom, two .sha1 files, and two .m2 internals:

_remote.repositories                  ← ~/.m2 internal
json-smart-2.4.11.jar.lastUpdated     ← ~/.m2 internal
json-smart-2.4.11.jar.sha1
json-smart-2.4.11.pom
json-smart-2.4.11.pom.lastUpdated     ← ~/.m2 internal
json-smart-2.4.11.pom.sha1

This is not carelessness — .gitignore line 116 is a blanket *.jar, and it silently dropped the jar from the git add. The four jars already in lib/maven-repo survive only because they were force-added years ago, and .gitignore doesn't apply to already-tracked files. So the rule has been lying in wait for anyone who vendors something new.

It got me too: my own first git add in #2037 lost the n5 jar exactly the same way, and I only caught it because git status listed five files where I expected six. #2037 adds !lib/maven-repo/**/*.jar so it can't happen again.

Without the jar, Maven reads the pom from lib/maven-repo, fails to find a jar beside it, and falls through to Central — the same path as before. So the branch is a no-op rather than a wrong fix.

Separately, _remote.repositories and *.lastUpdated are Maven Resolver's local-repo bookkeeping and shouldn't be in a file:// repository. The committed json-smart-2.4.11.jar.lastUpdated actually records why the source .m2 had no jar to copy:

https://maven.scijava.org/...error=Could not transfer artifact
net.minidev:json-smart:jar:2.4.11 from/to scijava.public: Read timed out

The cache entry it was copied from was a failed download.

2. Vendoring json-smart couldn't have fixed this even done correctly

This is the part I'd have got wrong too. The json-smart jar was never missing. Central serves it, and every module was already resolving it from there — you can see it in the failing log: Copying artifact 'net.minidev:json-smart:jar:2.4.8' ... to vcell-client/target/maven-jars/.

What failed was maven-metadata.xml, because com.nimbusds:oauth2-oidc-sdk:10.7 declares json-smart as a version range [1.3.3,2.4.8], and a range makes Maven fetch metadata from every repository. A file:// repository can't satisfy that — there's no metadata file to vendor. So no amount of vendoring the artifact addresses it.

#2037 removes the range instead (pins json-smart in root dependencyManagement), which stops the metadata fetch happening at all. Nice side effect: vcell-rest was pinning 2.4.11 while every other module silently took 2.4.8 off the top of the range. They all agree now.

3. json-smart wasn't even the whole cause

The json-smart 503 was the only visible scijava message in the log, so it looked like the culprit. It wasn't — or not alone. -X showed a second, invisible one:

Caused by: ArtifactResolutionException:
  org.jboss.narayana.jts:idlj-idl-openjdk:pom:7.0.0.Final (absent):
  Could not transfer ... from/to scijava.public: status code: 503

That artifact (via quarkus-agroal → quarkus-narayana-jta) exists in no repository at all. Central, jitpack and terracotta all 404 it and Maven shrugs — but scijava was returning 503, and Maven treats a 503 as a hard error where a 404 is just "ask the next one". The enforcer's DependencyConvergence rule then discarded the cause and reported only Could not build dependency tree, which is why the log pointed at the wrong artifact. Filed as #2038.

Root cause, for the record: scijava serves stored files fine (n5-3.0.0.pom and .jar both 200) but 503s everything Nexus generates — maven-metadata.xml and every .sha1. #2037 drops the repository entirely, after vendoring the one artifact it was actually serving (org.janelia.saalfeldlab:n5:3.0.0 — measured on a cold repo: central 1366, jitpack 15, lib-maven-repo 9, scijava 2, ej-technologies 2, terracotta 1).

Leaving the branch itself in place — nothing here needs deleting, and the .lastUpdated file is a useful bit of evidence.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx