Skip to content

fix(manifest): resolve Maven modules inside their class realm - #1715

Merged
Jeppe Fredsgaard Blaabjerg (jfblaa) merged 2 commits into
v1.xfrom
jfblaa/maven-project-realm
Nov 12, 2026
Merged

Jeppe Fredsgaard Blaabjerg (jfblaa) merged 2 commits into
v1.xfrom
jfblaa/maven-project-realm

Conversation

@jfblaa

Copy link
Copy Markdown
Contributor

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

Maven Socket facts now honor artifact types that a build's extensions define. Maven resolves a project inside its class realm, where those types are visible. The facts extension resolved each module after the build, outside that realm, so such a type fell back to Maven's default handler. A type that includes its own dependencies was then traversed anyway, and under --with-files its file was requested with the wrong extension. Each module is now resolved inside its project's class realm, as Maven's LifecycleDependencyResolver does.

Found by comparing Maven facts with the complete-edge ground truth of SocketDev/sbom-accuracy#631. Two projects whose modules use a build-extension packaging gave 182 components where Maven's own dependency:tree has 174. With this change both match the ground truth exactly.

Verification

  • New maven-compat/extension-type fixture: a build extension that only registers Maven's own artifact handler for a type that includes its dependencies. Maven's dependency:tree lists the dependency without its child. The extension now matches that, and fetches the .jar. Before this change it emitted the child and reported the artifact as unfetchable.
  • Maven compat matrix 3.2.5 to 4.0.0-rc-6 green.

Resolves REA-1163.

🤖 Generated with Claude Code

@cursor

cursor Bot commented Nov 12, 2026 •

Copy link
Copy Markdown

PR Summary

Medium Risk
Changes Maven dependency graph emission used for SBOMs and reachability; scope is narrow with a dedicated compat regression test.

Overview
Maven Socket facts generation now resolves each reactor module with that module's class realm as the thread context class loader, matching Maven's LifecycleDependencyResolver. Build extensions that register custom artifact types (for example a fat type that includes dependencies and maps to .jar) are visible during resolution, so facts no longer traverse dependencies Maven treats as bundled and --with-files fetches the correct extension.

A maven-compat regression (extension-type fixture plus smoke-test-extension-type.sh) asserts demo.ext:fat is emitted with fat-1.0.jar while demo.ext:inner is not listed; the compat matrix runner invokes it for every Maven version.

Reviewed by Cursor Bugbot for commit 3387b47. Configure here.

Maven resolves a project inside its class realm, where the artifact
types its build extensions define are visible (LifecycleDependencyResolver).
The facts extension resolved each module after the build, outside that
realm, so such a type fell back to Maven's default handler: a type that
includes its dependencies was traversed anyway, and its file extension
was wrong for --with-files. Each module is now resolved inside its
project's class realm.

Resolves REA-1163.
@jfblaa
Jeppe Fredsgaard Blaabjerg (jfblaa) merged commit 78206c7 into v1.x Nov 12, 2026
23 checks passed
@jfblaa
Jeppe Fredsgaard Blaabjerg (jfblaa) deleted the jfblaa/maven-project-realm branch November 12, 2026 16:01
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