Out of the review of #95, which shipped the pom.xml parser and the POM arm of parse_project.
Severity: medium (a monorepo cannot link a module to the dependencies on it)
Location: crates/dependable-core/src/parsers/project.rs — pom(); consumed by crates/dependable-fetch/src/tree.rs (workspace_names, built from parse_project(...).name).
Claim. #95 established that a POM's identity is its coordinate, groupId:artifactId — "the same way the POM parser names the dependencies it reads, so a project and a dependency on it are the same string". But when <groupId> is absent from <project>, the project is named by the bare artifactId instead, and the promise breaks: pom_xml still spells a dependency on that module org.x:child, while the module itself is called child. The two never match.
Failure scenario. A Maven multi-module build — the dominant shape, and the one where a <parent> supplies the group precisely so the children need not repeat it:
<!-- modules/child/pom.xml -->
<project>
<parent>
<groupId>org.x</groupId>
<artifactId>app-parent</artifactId>
<version>1.0.0</version>
</parent>
<artifactId>child</artifactId>
</project>and a sibling that depends on it as org.x:child. tree builds workspace_names from the project names, so org.x:child is not in the set: the sibling's edge is treated as external rather than as an edge to a module in this repository, and child appears in the graph as a root nothing depends on. The link a monorepo view exists to draw is exactly the one that is missing.
The value is in the file: <parent><groupId> is written right there, and Maven's own inheritance rule is that a missing <groupId> is the parent's. Reading it needs no IO and no registry. #95's doc comment declines it as "half guessed", but the guess is only half of one — the parent element states the group explicitly.
Not repaired here because it changes the identity string a shipped ecosystem reports (ProjectMeta::name, list's name field, and the tree node label) for every POM that inherits its group, which is a compatibility decision beyond the review's mandate.
Remediation direction. In pom(), fall back to <parent><groupId> when <project><groupId> is absent, matching Maven's inheritance rule, and do the same for <version> (<parent><version>) — an inheriting POM knows its own version by the same route. Then decide whether pom_xml should resolve the ${project.groupId} / ${project.version} built-ins from the same two sources, which would let the sibling-module idiom in #95 (PackageSource::Unidentified) resolve to a real coordinate instead. Add a test asserting that a child POM's own name and a sibling's dependency on it are the same string. Related: #98.
Out of the review of #95, which shipped the
pom.xmlparser and the POM arm ofparse_project.Severity: medium (a monorepo cannot link a module to the dependencies on it)
Location:
crates/dependable-core/src/parsers/project.rs—pom(); consumed bycrates/dependable-fetch/src/tree.rs(workspace_names, built fromparse_project(...).name).Claim. #95 established that a POM's identity is its coordinate,
groupId:artifactId— "the same way the POM parser names the dependencies it reads, so a project and a dependency on it are the same string". But when<groupId>is absent from<project>, the project is named by the bareartifactIdinstead, and the promise breaks:pom_xmlstill spells a dependency on that moduleorg.x:child, while the module itself is calledchild. The two never match.Failure scenario. A Maven multi-module build — the dominant shape, and the one where a
<parent>supplies the group precisely so the children need not repeat it:and a sibling that depends on it as
org.x:child.treebuildsworkspace_namesfrom the project names, soorg.x:childis not in the set: the sibling's edge is treated as external rather than as an edge to a module in this repository, andchildappears in the graph as a root nothing depends on. The link a monorepo view exists to draw is exactly the one that is missing.The value is in the file:
<parent><groupId>is written right there, and Maven's own inheritance rule is that a missing<groupId>is the parent's. Reading it needs no IO and no registry. #95's doc comment declines it as "half guessed", but the guess is only half of one — the parent element states the group explicitly.Not repaired here because it changes the identity string a shipped ecosystem reports (
ProjectMeta::name,list'snamefield, and thetreenode label) for every POM that inherits its group, which is a compatibility decision beyond the review's mandate.Remediation direction. In
pom(), fall back to<parent><groupId>when<project><groupId>is absent, matching Maven's inheritance rule, and do the same for<version>(<parent><version>) — an inheriting POM knows its own version by the same route. Then decide whetherpom_xmlshould resolve the${project.groupId}/${project.version}built-ins from the same two sources, which would let the sibling-module idiom in #95 (PackageSource::Unidentified) resolve to a real coordinate instead. Add a test asserting that a child POM's own name and a sibling's dependency on it are the same string. Related: #98.