Conversation
MergeCommand now calls CycloneDXUtils.FlatMerge/HierarchicalMerge with MergeStrategy.Default() when built against a library that has it (#if NET8_0_OR_GREATER, matching the library's own guard -- CLI is net10.0-only today but this keeps the two projects' conditional compilation symmetric and self-documenting), falling back to the plain overload otherwise. No new CLI flags: strategy toggles are not yet exposed at the command-line layer, so this only changes default merge behavior, not the command's surface. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Adds a "rename-entity" command that renames a bom-ref and every back-reference to it throughout a BOM document, built on the library's new BomRefWalker-based Bom.RenameRef(old, new) API. Follows current System.CommandLine conventions (System.CommandLine.NamingConventionBinder, not the older System.CommandLine.Invocation namespace) and matches Convert/ MergeCommand's internal (not public) visibility. Verified end-to-end against a real fixture: renaming a component's bom-ref correctly rewrites both the dependsOn back-reference and the dependency's own ref entry, and stamps fresh SerialNumber/Timestamp/ Tools metadata via BomMetadataUpdate/BomMetadataReferThisToolkit. Wired into Program.cs (alphabetical position, between Merge and Sign), guarded by #if NET8_0_OR_GREATER to match the library capability it depends on. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Follows MergeTests.cs conventions: direct handler call, TempDirectory, Snapshooter with serialNumber/timestamp stripped (plus the tools list, whose contents are build/environment-specific -- assembly versions and "testhost" vs. the real CLI name under `dotnet test`). Covers a JSON and an XML output round-trip of the rewrite-identifier-and-back-refs case, plus a no-op case when the requested old-ref isn't present. Full suite: 132 passed / 0 failed (129 pre-existing + 3 new). Signed-off-by: Jim Klimov <jimklimov@gmail.com>
…usal merge gains --component-conflict-resolution <KeepSeparate|Squash_UpgradeScope|Squash_DowngradeScope|Squash_RenameByScope>, defaulting to the library's MergeStrategy.Default() (Squash_UpgradeScope) when not specified. This closes a pre-existing gap: the library-side strategy was never selectable from the CLI at all -- it was always hardcoded to Default() internally. Verified end-to-end: merging two BOMs where the same component is "required" in one and "excluded" in the other with --component-conflict-resolution Squash_RenameByScope produces two distinct components (lp:scope=Required / lp:scope=Excluded) with each source's dependsOn correctly pointing at its own variant. rename-entity now catches the InvalidOperationException Bom.RenameRef throws when the requested new-ref collides with an existing identifier, reporting it as a clean parameter-validation error instead of an unhandled crash. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
This lets callers pass files listing BOM filenames (one per line, or 0x00-separated for the --input-files-nul-list variant, e.g. from `find -print0`) instead of one --input-files argument per BOM, to avoid OS/shell command-line length or argument-count limits when merging many BOMs, a real constraint once the number of input files grows large. Entries are deduplicated against --input-files and each other as they are collected. Non-absolute paths are resolved relative to the current working directory. No library changes needed -- this feature only builds a longer input-file list before the existing InputBoms(...) call. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Previously, when a flat merge specified a subject component (--group/ --name/--version), MergeCommand set Metadata.Component directly and never called the FlatMerge overload that accepts a subject component. As a result the merged document's dependency graph never linked the subject to the components each input BOM contributed -- no "<dependency ref="subject"><dependsOn>...` entry ever appeared, unlike a hierarchical merge with the same options. Calling FlatMerge(inputBoms, bomSubject, ...) instead lets the library build that dependency entry itself (namespacing the subject's bom-ref and linking it to each input BOM's own metadata component), matching what hierarchical merge already does. The "pick the first input BOM's component as a default" fallback still runs, but only when no subject was requested at all. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Replaces manually setting Version/SerialNumber/Timestamp inline with Bom.BomMetadataUpdate(true) and Bom.BomMetadataReferThisToolkit(). The manual version never recorded which library/tool produced the merged document at all -- Metadata.Tools was left exactly as whichever input BOM happened to contribute one, or absent entirely. The merged document now carries an entry for this library and the running program, the same way validate/convert/sign already leave a traceable record of what processed a document. Updates MergeTests' snapshot-cleanup regex to also strip the tools block before comparison, since its contents (assembly name/version) are build-environment-specific -- same treatment already used for other commands' tests. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Calls the library's new CleanupMetadataComponent/CleanupEmptyLists on the merged document. Complements the library-side change (which already covers this for a merge that requests an explicit BOM subject): when MergeCommand falls back to picking the first input BOM's own metadata component as the subject, that same component can also be present in the merged Components list, producing two entries with the same bom-ref -- a specification violation the library-level cleanup couldn't see, since the CLI's fallback selection happens after the library call returns. CleanupEmptyLists also drops now-empty top-level lists (e.g. an empty "vulnerabilities": []) that a flat merge of BOMs with no vulnerabilities previously left in the output. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
This was referenced Sep 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
FlatMergeso the merged document's dependency graph stays linked to it.Metadata.Toolson the merged document via the library'sBomMetadataUpdate().library's
CleanupMetadataComponent()/CleanupEmptyLists().Why
Supersedes both #340 (
bom-self-metadata) and #334 (flatmerge-dedup-squash) — in the currentcodebase these turned out to be one coherent change to
MergeCommand.csrather than two separateconcerns, so they're combined here instead of kept as two like-for-like PRs. Closing both in favor of
this PR.
Depends on cyclonedx-dotnet-library#446
(
BomMetadataUpdate) and #448(
CleanupMetadataComponent/CleanupEmptyLists). Stacked on #512 (merge-input-files-list) — mustmerge first.