Repository navigation
fix(manifest): resolve Maven modules inside their class realm - #1715
Conversation
PR SummaryMedium Risk Overview A maven-compat regression ( 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.
3387b47 to
33e37f4
Compare
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-filesits file was requested with the wrong extension. Each module is now resolved inside its project's class realm, as Maven'sLifecycleDependencyResolverdoes.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:treehas 174. With this change both match the ground truth exactly.Verification
maven-compat/extension-typefixture: a build extension that only registers Maven's own artifact handler for a type that includes its dependencies. Maven'sdependency:treelists 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.Resolves REA-1163.
🤖 Generated with Claude Code