Skip to content

fix(manifest): report the Maven POMs that Maven only warns about - #1646

Merged
Jeppe Fredsgaard Blaabjerg (jfblaa) merged 6 commits into
jfblaa/maven-facts-partial-graph-materializefrom
jfblaa/maven-facts-tolerated-poms
Oct 23, 2026
Merged

Jeppe Fredsgaard Blaabjerg (jfblaa) merged 6 commits into
jfblaa/maven-facts-partial-graph-materializefrom
jfblaa/maven-facts-tolerated-poms

Conversation

@jfblaa

@jfblaa Jeppe Fredsgaard Blaabjerg (jfblaa) commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

LLM Description written by Claude Code:claude-opus-5-5

Maven's default descriptor policy tolerates a missing or invalid POM: the node stays, its dependencies are lost, and no collection error is raised. The resolver also caches a failed POM build-wide, so only the first module to reach it saw the failure.

  • Repository events of collection are observed (CoanaFactsEventSpy → CollectionObserver) so both cases are reported in every module that uses the POM.
  • A failure absent from the graph gets the scope Maven would have given it, so excludeConfigs and version-conflict losers no longer over-block.
  • system-scope jars get their files.
  • New classifier rules: HTTP blocker and offline mode as repository errors, tolerated invalid POMs as POM problems, repository filters as not found.

Testing: new descriptor-failure compat suite, graph-failure expectations updated for scope placement; both pass on Maven 3.2.5–4.0.0-rc-6. New classification unit tests.

🤖 Generated with Claude Code


Note

Medium Risk
Changes how Maven dependency failures are detected, scoped, and emitted into Socket facts, which directly affects whether scans block, what reaches reachability analysis, and multi-module reporting accuracy across Maven 3.2–4.x.

Overview
Maven Socket facts collection now surfaces dependency problems Maven’s resolver often only warns about or caches silently, so manifest and reachability runs get accurate failure records instead of incomplete graphs.

A new CoanaFactsEventSpy / CollectionObserver path listens to Aether repository events during collection and feeds SocketFactsRecordsEngine, which reports missing or invalid POMs in every reactor module that uses them (including when a prior module already cached the failure). Failures absent from the graph are attributed to the right scope (with Maven 3.9+ collect-step tracing where available), so excludeConfigs and version-conflict losers no longer block unrelated scopes. system-scope artifacts are included in file materialization again.

CLI resolution reporting gains Maven-specific classification (HTTP blocker, offline mode, tolerated invalid POMs, repository prefix filters), plus a descriptor-failure compat smoke test and updated graph-failure expectations.

Reviewed by Cursor Bugbot for commit 506d191. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Fix All in Cursor

Bugbot Autofix is ON, but none of the reported issues met your autofix severity threshold.

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

Reviewed by Cursor Bugbot for commit 506d191. Configure here.

@mtorp Martin Torp (mtorp) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[agent] Approving, with three inline notes on scope placement.

Separately, this PR makes jar-only artifacts, POMs Maven tolerates as invalid, and system dependencies with a missing systemPath (like jdk.tools on JDK 9+) block the scan, even though the build itself passes. I left a note on #1647 about that policy for the whole stack.

Maven's default descriptor policy tolerates a missing or invalid POM:
the node stays, its dependencies are lost, and no collection error is
raised. The resolver also caches a failed POM build-wide, so only the
first module to reach it saw the failure. The facts extension now
observes the repository events of collection to report both in every
module that uses them, places a failure absent from the graph in the
scope Maven would have given it, and materializes system-scope jars.
…cached POM failure

Replaying another module's cached POM failure matched any version-range
declaration of the same artifact, so a module whose range resolved to a
healthy version inherited the failure. A direct dependency never loses a
conflict, so one still among the graph's direct children resolved.
…its parent

The collector reuses a parent's children for every later instance of its
artifact, so a failing collect step ran only under the first instance;
when that instance lost a conflict, the failure was dropped. Any
classpath instance of the parent now places it. A scope the module
manages is kept as Maven's conflict resolver keeps it, not derived.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… parent's children

An instance of the parent with its own exclusions gets its own child
list, so matching the parent by coordinate placed a failure that Maven
excludes from the classpath instance.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…he keys on

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@jfblaa
Jeppe Fredsgaard Blaabjerg (jfblaa) merged commit 18ed2ae into v1.x Oct 23, 2026
12 of 14 checks passed
@jfblaa
Jeppe Fredsgaard Blaabjerg (jfblaa) deleted the jfblaa/maven-facts-tolerated-poms branch October 23, 2026 17:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants