license list: format json with the same structure as csv, text and md. #130
Conversation
fixes CycloneDX#76, supports --summary, not entirely sure why the JSON structure is different, note that this is a breaking change to the format, so open to any suggestions/guidance on new flags that should be introduced to control behaviour here. Signed-off-by: Quentin Quaadgras <[email protected]>
Splizard
changed the title
|
@Splizard will try to look at the PR next week after vacation, but the JSON was supposed to be true to the CycloneDX schema; whereas the "summary" was my own opinionated decision of what I believed was important to my company's CISO. Conceptually the JSON structs were supposed to only be CycloneDX to allow tools to extract the dat objects from one BOM and use them in another BOM. |
|
@Splizard Can we get together to discuss an approach to achieve what you like, but not create JSON that does not adhere to the CycloneDX schema? |
|
|
||
| for _, licenseName := range bom.LicenseMap.KeySet() { | ||
| arrLicenseInfo, _ := bom.LicenseMap.Get(licenseName) | ||
|
|
||
| for _, iInfo := range arrLicenseInfo { | ||
| licenseInfo = iInfo.(schema.LicenseInfo) | ||
| if licenseInfo.LicenseChoiceTypeValue != schema.LC_TYPE_INVALID { | ||
| lc = append(lc, licenseInfo.LicenseChoice) | ||
| line, err = prepareReportLineData( |
There was a problem hiding this comment.
In alignment with my statements regarding that the JSON produced needs to match the CycloneDX schema (as the default), I believe the correct approach that achieves what you like (and set a precedent for other APIs as well) would be to conditionally generate the non-standard JSON output only if the --summary flag was also provided in addition the --format json flag and value.
fixes #76, supports --summary, not entirely sure why the JSON structure is different, note that this is a breaking change to the format, so open to any suggestions/guidance on flags that should be introduced to control this behavior.