Out of the review of #95, which shipped the pom.xml parser.
Severity: low–medium (silent under-reporting)
Location: crates/dependable-core/src/parsers/pom_xml.rs — read_dependencies (only <dependencies> directly under <project> is read) and profile_notice.
Claim. #95 reads exactly one element — the <dependencies> directly under <project> — and deliberately excludes three others: <profiles>, <dependencyManagement>, and <build><plugins>. It announces only the first. profile_notice puts a line on stderr and into ParsedManifest::notices, on the stated grounds that
a POM that declares every one of its dependencies inside a profile then lists as (0 dependencies), which reads as complete and is not.
That reasoning applies unchanged to the other two exclusions, which stay silent.
Failure scenario. A pom.xml that keeps its versions in <dependencyManagement> and declares nothing under <project><dependencies> — a legitimate shape for an aggregator or BOM-style module — lists as (0 dependencies) with nothing at all on stderr. A reader comparing dependable list against the file they are looking at sees a list that reads as complete and is not, which is the exact condition the <profiles> notice exists to end. The same holds for a <build><plugins> block whose plugins carry their own <version> and their own advisories: a plugin is not a dependency of the artifact, but a reader is never told the run declined to look.
Not repaired here because #95's review mandate covered the entries the parser does emit; adding two notices changes what every existing JVM run prints on stderr and is a deliberate output decision of its own.
Remediation direction. Give each excluded element the treatment <profiles> already has: count what was skipped and say so once per manifest through ParsedManifest::notices. The wording should keep the three apart — a profile applies conditionally, <dependencyManagement> states versions for dependencies declared elsewhere, and a plugin describes the build rather than the artifact — because those are three different reasons to have looked away. Alternatively, decide explicitly and in writing that only a conditional omission warrants a notice, and record that as the rule the parser follows.
Out of the review of #95, which shipped the
pom.xmlparser.Severity: low–medium (silent under-reporting)
Location:
crates/dependable-core/src/parsers/pom_xml.rs—read_dependencies(only<dependencies>directly under<project>is read) andprofile_notice.Claim. #95 reads exactly one element — the
<dependencies>directly under<project>— and deliberately excludes three others:<profiles>,<dependencyManagement>, and<build><plugins>. It announces only the first.profile_noticeputs a line on stderr and intoParsedManifest::notices, on the stated grounds thatThat reasoning applies unchanged to the other two exclusions, which stay silent.
Failure scenario. A
pom.xmlthat keeps its versions in<dependencyManagement>and declares nothing under<project><dependencies>— a legitimate shape for an aggregator or BOM-style module — lists as(0 dependencies)with nothing at all on stderr. A reader comparingdependable listagainst the file they are looking at sees a list that reads as complete and is not, which is the exact condition the<profiles>notice exists to end. The same holds for a<build><plugins>block whose plugins carry their own<version>and their own advisories: a plugin is not a dependency of the artifact, but a reader is never told the run declined to look.Not repaired here because #95's review mandate covered the entries the parser does emit; adding two notices changes what every existing JVM run prints on stderr and is a deliberate output decision of its own.
Remediation direction. Give each excluded element the treatment
<profiles>already has: count what was skipped and say so once per manifest throughParsedManifest::notices. The wording should keep the three apart — a profile applies conditionally,<dependencyManagement>states versions for dependencies declared elsewhere, and a plugin describes the build rather than the artifact — because those are three different reasons to have looked away. Alternatively, decide explicitly and in writing that only a conditional omission warrants a notice, and record that as the rule the parser follows.