build(deps): drop the scijava repository, vendor n5, and remove the last version range - #2037
Merged
Conversation
maven.scijava.org served exactly one artifact in the whole reactor:
org.janelia.saalfeldlab:n5:3.0.0, used by N5Exporter and genuinely absent
from Central (the entire groupId 404s there). Measured on a cold local
repository: central 1366, jitpack 15, lib-maven-repo 9, scijava 2, ej-
technologies 2, terracotta 1.
Keeping a server on the critical path for one 95 kB jar would be a poor
trade even if it were healthy, and it is not. It currently serves stored
files normally (n5-3.0.0.pom and .jar both 200) while returning 503 for
every file Nexus generates - maven-metadata.xml and every .sha1. Maven
reads a 404 as "ask the next repository" but a 503 as a hard transfer
error, so that state turned two harmless situations fatal:
- org.jboss.narayana.jts:idlj-idl-openjdk:pom:7.0.0.Final, pulled in via
quarkus-agroal -> quarkus-narayana-jta, exists in NO repository. Every
other repo 404s and Maven shrugs; scijava's 503 did not let it.
- the net.minidev:json-smart version range needs maven-metadata.xml from
every repository, and scijava 503s all of it.
Both only surfaced inside the enforcer's DependencyConvergence rule, which
calls collectDependencies and reports the result as "Could not build
dependency tree" with the cause swallowed - which is why every other module
compiled and only vcell-rest failed.
With n5 vendored, a build from an empty local repository succeeds without
contacting maven.scijava.org at all.
.gitignore needed the negation: the blanket *.jar rule silently swallows
the jar of anything vendored under lib/maven-repo. The four jars already
there predate it and survive only because tracked files ignore .gitignore.
That trap is not hypothetical - it is why the earlier attempt to vendor
json-smart committed a pom and a checksum with no jar behind them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx
com.nimbusds:oauth2-oidc-sdk:10.7 declares net.minidev:json-smart as the range [1.3.3,2.4.8]. A range is the only thing in this entire build that makes Maven fetch maven-metadata.xml, and it must then fetch it from every declared repository - so any repository answering with a transfer error rather than a 404 fails the whole dependency collection. Managing the version replaces the range before it is ever resolved. Measured: a cold build requests maven-metadata.xml exactly once, for net.minidev:json-smart, and zero times with this block present. It also closes a version split that was never intentional. vcell-rest declared json-smart 2.4.11 directly and excluded it from oauth2-oidc-sdk, but every other module reached it only through the range and silently took 2.4.8, the top of that range. All modules now agree on the managed version. Removing the scijava repository already unblocks the build on its own; this is the other half - it removes the mechanism rather than one server that happened to trip it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx
This was referenced Aug 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the
vcell-restenforcer failure in run 33104159035.What actually broke
maven.scijava.orgis not down. It serves stored files fine and 503s on everything Nexus generates. Reproducible, 3/3 tries:…/n5/3.0.0/n5-3.0.0.pom…/n5/3.0.0/n5-3.0.0.jar…/n5/3.0.0/n5-3.0.0.jar.sha1…/<anything>/maven-metadata.xmlMaven reads a 404 as "not here, ask the next repository" but a 503 as a hard transfer error. A repository in that state turns two otherwise harmless situations fatal, and both are in our tree:
org.jboss.narayana.jts:idlj-idl-openjdk:pom:7.0.0.Final— reached viaquarkus-agroal→quarkus-narayana-jta, and it exists in no repository at all. Central, jitpack and terracotta all 404 and Maven shrugs. scijava's 503 did not let it.com.nimbusds:oauth2-oidc-sdk:10.7declaresnet.minidev:json-smart:[1.3.3,2.4.8]— a version range, and a range forcesmaven-metadata.xmlfrom every repository. It is the only range in the entire build.Both surface only inside the enforcer's
DependencyConvergencerule, which callscollectDependenciesand reportsCould not build dependency treewith the cause swallowed. That is why 13 modules compiled and onlyvcell-restfailed — and why cause (1) was invisible in the CI log. It took-Xto see.Which artifacts actually come from scijava
Measured on a cold local repository, not inferred — the local
.m2is useless for this (historical repo ordering leaves ~1140 false positives):Those 2 are the pom and jar of
org.janelia.saalfeldlab:n5:3.0.0— one artifact, used bycbit.vcell.export.server.N5Exporter, genuinely absent from Central (the whole groupId 404s). Its parentorg.scijava:pom-scijava:34.0.0and all its runtime dependencies do come from Central.So the answer to "should we vendor them all" is yes — and "all" is one 95 kB jar.
The changes
build(deps): vendor n5 and drop the scijava repositoryVendors
n5:3.0.0intolib/maven-repo(jar, pom, locally-computed.sha1/.md5) and removes thescijava.publicrepository, with the measurements recorded in the comment.Also adds
!lib/maven-repo/**/*.jarto.gitignore. The blanket*.jarat line 116 silently swallows the jar of anything vendored there — the four jars already present survive only because they were force-added long ago and tracked files ignore.gitignore. My own firstgit addlost the n5 jar to it.build(deps): pin json-smart so no version range is left in the buildManages
net.minidev:json-smartin the root POM so the range is replaced before it is ever resolved. Also closes an unintended split:vcell-restdeclared 2.4.11 directly, while every other module silently took 2.4.8, the top of the range.Verification
Each fix was tested independently against a cold repository carrying the exact CI state (cached scijava 503) — removing the repository fixes the build without the pin, and the pin removes the metadata fetch (1 → 0) without touching the repository list.
With both, from a completely empty local repository:
mvn install -DskipTests→ BUILD SUCCESSgrep -ci scijava.orgover the full log → 0maven-metadata.xmlrequests → only our ownvcell-restSNAPSHOT (404, harmless)file://…/lib/maven-repoOn
dan-json-smartRecommend closing rather than merging. That commit vendors a pom and two checksums with no jar —
.gitignoredropped it — so Maven reads the pom fromlib/maven-repo, misses the jar, and falls through to Central exactly as before. The committed.lastUpdatedfile records why his cache had no jar:Could not transfer artifact net.minidev:json-smart:jar:2.4.11 … Read timed out. It also commits_remote.repositoriesand.lastUpdated, which are~/.m2internals that should not be in afile://repository.More fundamentally, vendoring json-smart could not have fixed this even done correctly: the jar was never missing. Central serves it and every module already resolved it from there. What failed was
maven-metadata.xml, which afile://repository cannot supply for a version range anyway.🤖 Generated with Claude Code
https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx