Include all supported manifest basenames

GetBuildFileTrees drops every manifest whose basename is not in this classifier. That misses SBOMs this generator actually emits for supported manifests such as Go (parse-go-lock.go marks go.mod occurrences as LocationRoleManifest) and requirements variants (RequirementsTxtExtractor.ShouldExtract accepts any requirements*.txt), so Go projects or files like requirements-dev.txt have manifest evidence in the SBOM but are absent from the returned build-file map. Please extend this classifier/pattern matching to cover the supported manifest inputs before applying the filter.

Useful? React with 👍 / 👎.

Normalize requirements variants before filtering

When callers pass FileTypeRequirementsTxt to filter for requirements manifests, supported files such as requirements-dev.txt are silently excluded: RequirementsTxtExtractor.ShouldExtract accepts any basename containing requirements and ending in .txt, and those occurrences are emitted with role=manifest, but this classifier returns the exact basename unless it is .csproj. As a result GetBuildFileTrees(sbom, FileTypeRequirementsTxt) returns nothing for these supported requirements SBOMs even though an unfiltered call would include them under a different ad-hoc FileType.

Useful? React with 👍 / 👎.

Preserve Maven artifact extraction by default

When the CLI calls DoScan, cmd/datadog-sbom-generator/scan/main.go constructs ScannerActions without setting this newly added option, so the zero value false is passed here and ExtractDeps skips every ArtifactExtractor. For Maven scans this drops the pom.xml file components and dependency edges that were previously emitted in CycloneDX output, which is visible in the updated CLI snapshots; either make the scanner default preserve the old behavior or set the new option in the CLI path.

Useful? React with 👍 / 👎.

No, it is intended to be removed

Restore Maven artifacts for custom options

When library callers build Options themselves (for example Options{Recursive: true} or any existing literal that predated this field), this new bool remains false and is passed through to DoScan, so ExtractDeps no longer runs ArtifactExtractor.GetArtifact for Maven pom.xml files. Before this change those callers always got the Maven file components and parent dependency edges in the generated CycloneDX SBOM; only callers that happen to use DefaultOptions() preserve that behavior.

Useful? React with 👍 / 👎.

No, it is intended to be removed

Inspect all occurrence sublocations for manifests

When a dependency occurrence has manifest evidence in name, namespace, or version whose filename differs from the declaration block, this only reads block and drops those files. Maven inheritance/property resolution already emits such occurrences (for example a child dependency block can have its version location in a parent pom.xml), so GetBuildFileTrees can omit a parent build file if it has no dependency block of its own. Please scan every PackageLocations sublocation with role=manifest, not just block.

Useful? React with 👍 / 👎.

This is a partial case, covering with the following comment

Include file-only POM components in the tree

When a Maven parent/aggregator POM has no dependency declarations of its own, the generated CycloneDX SBOM can still contain it as a file component and dependency target, but it has no evidence occurrences. This branch skips every component without Evidence.Occurrences, so that POM is never added to filesByPath; MavenProcessor then ignores child → parent edges to it and returns children with no parent, producing an incomplete build-file tree for common multi-module layouts where the root POM only defines modules/properties.

Useful? React with 👍 / 👎.

Don't treat module dependencies as Maven parents

When a Maven POM has dependencies on other local modules, the SBOM dependency entry can contain those module POMs as well as the real parent POM: internal/output/sbom/cyclonedx.go adds artifact.Filename for internal Maven dependencies and sorts the list. This loop then treats the first known POM dependency as the parent, so cases like a module depending on a sibling module (or a root POM depending on a child module) produce incorrect parent/child build-file trees even though the edge is not from the <parent> element.

Useful? React with 👍 / 👎.

Normalize SBOM paths before deriving file types

When GetBuildFileTrees parses an SBOM generated on Windows but is called on a Unix host, occurrence paths such as backend\Cargo.toml are passed to filepath.Base, which treats backslashes as ordinary characters on Unix. The resulting FileType becomes backend\Cargo.toml instead of Cargo.toml, so filtering with FileTypeCargoToml drops the manifest and unfiltered results are grouped under the wrong type; normalize \ separators or use a platform-independent basename before classification.

Useful? React with 👍 / 👎.

Normalize build file paths to the repo root

When callers pass an SBOM produced by GenerateSBOM or the CLI, this stores the raw file_name/BOMRef in BuildFile.FilePath, but those values are absolute paths: scanDir converts walked files with filepath.Abs, OpenLocalDepFile also absolutizes them, and extractors write f.Path() into package locations/artifacts. That makes the new API return machine-specific absolute paths despite the BuildFile.FilePath contract saying it is repo-relative, so consumers cannot reliably compare results across workspaces or use the documented path semantics.

Useful? React with 👍 / 👎.

Handle requirements.in manifests in filters

When a requirements.in source file exists, RequirementsInMatcher marks matched packages with LocationRoleManifest and uses the .in path as the occurrence filename, but this classifier only normalizes requirements*.txt. As a result GetBuildFileTrees(sbom, FileTypeRequirementsTxt) silently drops supported requirements manifests such as requirements.in or requirements-dev.in even though they are present in the SBOM; normalize these .in basenames to a requirements file type or expose a filterable FileType for them.

Useful? React with 👍 / 👎.

Not for now

Populate Maven IDs when groupId is inherited

When a Maven module omits <groupId> and inherits it from its parent, the file component purl generated by the existing artifact extractor has no namespace (the repo fixture other-dir/pom.xml is one such case, producing a value like pkg:maven/kafka-commons-client@...). Since the new API derives BuildFileRelations.ID only through parseMavenArtifactID, that common module shape gets an empty ID even though the README/API contract says Maven IDs are groupId:artifactId; resolve inherited group IDs or derive them through the parent metadata before storing this map entry.

Useful? React with 👍 / 👎.

the fact that we make it a default-ignore, means that we are changing the default behavior of the tool (which used to be default-add). I guess it's not a big deal if we didn't use it! did we? 👀

It was intentional and something @marcwieserdev and I discussed

now in the datadog-sbom-generator it seems we only have tests with false. which means we no longer have a single example of main_test.snap with the flag true. Could we add at least one?

the main_test.snap is a very easy way to test and understand actual generated sbom (they are more human readable than the Go tests)

could we make it consistent with the other component properties we have? they are prefixed with datadog.

Except of course if it's a global known property

if we now afford to change the default to the EXCLUDE the artifact, i assume it means we don't really have consumer of this property: osv-scanner:package ?
Should we take this opportunity to also standardize the name to: datadog:package? or whatever else which would make sense?

looks like this map is set/populated but never read. Is that a building block which is a leftover? or a component which will be used later?

nitpick: i think this comment is due next to: buildProcessorContext definition? :p

Return SBOMs when only Maven build files are found

With this option enabled, scanDir can now return Maven artifacts even when no packages were extracted, such as a repository that only contains parent/aggregator pom.xml files with no dependency declarations. GenerateSBOM still bubbles DoScan's NoPackagesFoundErr because DoScan checks only len(scannedPackages), so callers cannot produce the SBOM needed by GetBuildFileTrees for these build-file-only projects; treat non-empty artifacts as a successful scan or include them before the empty-package check.

Useful? React with 👍 / 👎.

Preserve scan root when deduplicating build files

When GenerateSBOM is called with multiple scan roots, DoScan serializes locations and artifacts relative to each root, so two different roots can both contribute a pom.xml/Cargo.toml path. Because RepoPath is left empty here and seen keys only on FileType and FilePath, GetBuildFileTrees collapses those distinct build files into one entry, losing a root and merging its relations; populate/use the root identity or otherwise make the SBOM refs unique across scan roots.

Useful? React with 👍 / 👎.