DependencyConvergence swallows the real resolution error, and it misdirects diagnosis

Aperta Adatta ai principianti
#2,038 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
74/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
documentation

Direzione di ricerca

Parti dall'elenco ordinato di correzioni nel corpo dell'issue: l'opzione 1 è un singolo paragrafo aggiunto a CLAUDE.md e/o a docs/BUILDING.md che dice ai lettori che Could not build dependency tree nasconde la causa reale e che devi rieseguire con -X e cercare Caused by. Prima di scriverlo, controlla dove il maven-enforcer-plugin (pinnato a 3.1.0) è configurato nei file di build per confermare il pin e vedere se una versione più recente propaga la causa (opzione 2). Fatto = il paragrafo finisce nella documentazione di build, oppure una nota spiega perché il pin deve restare; lascia fuori l'opzione 3 (eseguire dependency:tree in CI) a meno che non venga richiesto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What happens

When dependency resolution fails for any reason, the enforcer's DependencyConvergence rule reports exactly this and nothing else:

[ERROR] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
Could not build dependency tree Could not collect dependencies: org.vcell:vcell-rest:jar:1.0.0-SNAPSHOT

The underlying ArtifactResolutionException — which names the artifact and the repository that failed — is discarded. maven-shared-dependency-tree wraps it in a DependencyCollectorBuilderException, and the rule only propagates getMessage().

Why it cost real time

This is what run 33104159035 looked like, and it is actively misleading. The only visible scijava-related message anywhere in that log was a [WARNING] about net.minidev:json-smart/maven-metadata.xml returning 503. Being the only clue, it read like the cause — and the first attempt at a fix went after json-smart specifically.

It was not the cause, or at least not the whole one. Running the same build with -X produced the real chain:

Caused by: DependencyCollectionException: Failed to collect dependencies at
    io.quarkus:quarkus-agroal:jar:3.5.2
 -> io.quarkus:quarkus-narayana-jta:jar:3.5.2
 -> org.jboss.narayana.jts:narayana-jts-integration:jar:7.0.0.Final
 -> org.jboss.narayana.jts:idlj-idl-openjdk:jar:7.0.0.Final
Caused by: ArtifactResolutionException: The following artifacts could not be resolved:
    org.jboss.narayana.jts:idlj-idl-openjdk:pom:7.0.0.Final (absent):
    Could not transfer artifact ... from/to scijava.public: status code: 503

A different artifact entirely, on a dependency path nobody would have guessed from the log. Both were symptoms of the same thing (scijava answering 503 where every other repository answers 404), but the message pointed at the wrong one.

The failure mode generalises: the rule reports the shape of the problem ("could not build the tree") while withholding the one fact needed to act on it (which artifact, which repository). It also fires only on the module that happens to have the rule bound, so the log reads as "vcell-rest is broken" when the real condition is repository-wide.

What to do about it

Ordered by cost:

  1. Document it. A line in CLAUDE.md / docs/BUILDING.md: if you see Could not build dependency tree, re-run with -X and grep for Caused by — the enforcer has hidden the real error. This is the cheap 90%.
  2. Check whether a newer enforcer helps. We pin maven-enforcer-plugin:3.1.0; later versions may propagate the cause. Worth a look before building anything.
  3. Surface the cause ourselves, if neither of the above is enough — e.g. run dependency:tree ahead of enforce in CI so a resolution failure reports itself properly before the enforcer gets to obscure it.

Context

Found while diagnosing #2037. Not urgent — nothing is broken by this — but it is the second time an enforcer message has sent a diagnosis in the wrong direction, and the fix in (1) costs one paragraph.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx

Lingua principale
Java
Stelle
140
Fork
35
Merge medio
22h 6m
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di virtualcell/vcell

Tutte le issue di virtualcell/vcell

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.