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.
This PR is yet another part of my larger proposal of Merge ability changes stacked in the PR queue.
It adds some utility methods to
Bom
class, so it can be in charge of initializing a (usuallynew
) Bom object into a usefully populated one, e.g. the mergeresult
to pile other Bom's into, while being the authoritative location to know and care about the class and data structure involved - well in OOP style.These methods allow the
Bom
object to initialize:Metadata/Tools
(now updated to match recent changes in upstream code of the library with aToolChoices
layer) pre-populated with the current version of thecyclonedx-dotnet-library
and if possible to discover - its consumer like thecyclonedx-cli
tool;Version=1
if this is a new document (or if explicitly requested by method argument), or increment theVersion
field if it is a re-iteration of an existing document.Library consumers which modify these fields directly (e.g.
MergeCommand.cs
incyclonedx-cli
) would benefit from being updated accordingly; a PR to this effect will be posted shortly.Calls to these methods were added to
HierarchicalMerge()
andFlatMerge(Boms, ...)
methods, to pre-populate theresult
object into which merged information would land, since after any processing we conceptually yield a new document.Note that it would be pedantically prudent to also do this in
FlatMerge(Bom, Bom)
method which does most of the actual merging work - however, it does so in a loop (called fromFlatMerge(Boms, ...)
) and in currentMerge.cs
codebase would just waste CPU time on detection or generation of needed information just to forget it with the next cycle. Still, it would be "correct" to populate this information for the benefit of (theoretically possible, not seen yet) "other consumers" who would only call this method directly, and not know/care about populating those fields on their own, whether "manually" or by using theBom
methods introduced here on the object that pops out from theFlatMerge()
call. I did not pursue this corner case here, because it is addressed differently (with an API change to pass toggles whether to do or skip such pre-init) in the larger solution for merge ability improvements.As it happens, this PR also fixes an issue reported earlier:
Closes: #183