Add dependency graph info to BoM

[ManjunathMS35]

This is related to the issue #61

Changes:

• Added dependencies info to the BoM so that the dependency tree can be derived out of this.

ToDo:

• Introduce new class by the name BomReference so that the creation of PackageUrl for both Component and Dependency is done through this single class

[jkowalleck]

this PR supersedes #243

[jkowalleck]

@ManjunathMS35
please don't confuse BomRefs with PackageURLs(PURL).
it might be appealing that a BomRef looks like a PURL, bit a BomRef might be any arbitrary string.

---

regarding your TODO:

Introduce new class by the name BomReference so that the creation of PackageUrl for both Component and Dependency is done through this single class

you might find this write-up/decision-paper from another CycloneDX project helpful: https://github.com/CycloneDX/cyclonedx-php-library/blob/master/docs/dev/decisions/BomDependencyDataModel.md
it might give you some ideas and point out some constraints. Since the other project is written in PHP, it might not be close to the JavaScript implementation and its needs.

[jkowalleck]

❗ there is code to crate a PURL already. see

cyclonedx-node-module/model/Component.js

Line 43 in b8f6940

if (this._name && this._version) { this._purl = new PackageURL('npm', this._group, this._name, this._version, null, null).toString() }

if you really want to use a PURL as the bom-ref's value, please incorporate the already existing PURL creation.
Reasons: if a bom-ref looks like a PURL, i would expect it to be the actual PURL of a Component, not a string that was crafted somehow else.

[ManjunathMS35]

This is the reason I wanted to implement the BomReference class and make use of creation of PURL in both Component and Bom. Is it okay to do something like this?

[ManjunathMS35]

@jkowalleck Any suggestions on this?

[jkowalleck]

see #244 (comment)

[jkowalleck]

❓
how do you handle, if this.createPackageURL() returns null? which is totally possible from the current algorithm used?

[ManjunathMS35]

Its not handled yet and as I said in the previous comment, creation of BomReference class will solve this issue.

[jkowalleck]

see #244 (comment)

[jkowalleck]

@ManjunathMS35, thanks for working on this feature. it is appreciated.

I am not too familiar with the JavaScript code base, so some of my latest comments might be not justified a 100%
Bare with me and help me understand things better :)

[ManjunathMS35]

@ManjunathMS35, thanks for working on this feature. it is appreciated.

I am not too familiar with the JavaScript code base, so some of my latest comments might be not justified a 100% Bare with me and help me understand things better :)

Even I am not familiar with best practices of JavaScript, I will try my best to answer your questions.

[jkowalleck]

will come back as soon as #247 was addressed.

[jkowalleck]

a good solution would be to "find" the component that is referenced in the already existing Bom.components,
and use its bomRef getter. this way you have the correct ref value, definitely.

need to think more about the topic. will come back later.

[jkowalleck]

re #244 (comment)

i think having dedicated Type for bom-ref/ref is the way to go. I would totally support the new Type for bom-ref/ref - it is in the spirit of CycloneDX/specification#114

A constraint i see: In the current major version the new type must extend String, because the current implementation of the component.bomRef returns string or undefined.

[jkowalleck]

superseded by #296