Incomplete manifest generated in case of intermediate issues in resolving artifacts

[goldmann]

We observed an issue with one of our generations recently which resulted in an incomplete manifest. Generated manifest had 63 components, but we expected 378. The only thing we found in the logs was this:

00:07:03,692 INFO  [org.jbo.sbo.cli.fea.sbo.gen.ProcessRunner] (main) [WARNING] An error occurred building dependency graph: Could not collect dependencies: org.kie.trustyai:explainability-service:jar:999.0.0.managedsvc-redhat-01048 mdc:[{buildId=BD2PHNKA6UAAA}]
00:07:03,703 INFO  [org.jbo.sbo.cli.fea.sbo.gen.ProcessRunner] (main) [INFO] CycloneDX: Creating BOM version 1.4 with 63 component(s) mdc:[{buildId=BD2PHNKA6UAAA}]
00:07:03,991 INFO  [org.jbo.sbo.cli.fea.sbo.gen.ProcessRunner] (main) [INFO] CycloneDX: Writing and validating BOM (JSON): /tmp/sbomer-workdir/product-0/target/bom.json mdc:[{buildId=BD2PHNKA6UAAA}]

This points us to this:

cyclonedx-maven-plugin/src/main/java/org/cyclonedx/maven/DefaultProjectDependenciesConverter.java

Lines 98 to 102 in db2a35b

	} catch (DependencyCollectorBuilderException e) {
	// When executing makeAggregateBom, some projects may not yet be built. Workaround is to warn on this
	// rather than throwing an exception https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/55
	logger.warn("An error occurred building dependency graph: " + e.getMessage());
	}

This was introduced as part of #55 in this commit 0666338 by @stevespringett.

For the record, here is a complete run:

5:32:41,092 INFO  [org.jbo.sbo.cli.fea.sbo.gen.ProcessRunner] (main) [INFO] CycloneDX: Creating BOM version 1.4 with 378 component(s) mdc:[{buildId=BD2PHNKA6UAAA}]
15:32:41,207 INFO  [org.jbo.sbo.cli.fea.sbo.gen.ProcessRunner] (main) [INFO] CycloneDX: Writing and validating BOM (JSON): /tmp/sbomer-workdir/product-0/target/bom.json mdc:[{buildId=BD2PHNKA6UAAA}]

I think this is a wrong approach. If we cannot build the dependency graph, we should not attempt to generate a partial manifest silently. If there is really a use case for it, it should be at least exposed via flag, but I still think continuing with manifest generation should be disabled by default.

[hboutemy]

being tolerant or strict, a common question: yes, perhaps we could add such a flag

I'd be interested to learn more about why this edge case happened to you: can you share (eventually in private) more details?
And one key question: are you using the plugin from command line, or through configuration in pom.xml? Aggregate or single?

[goldmann]

Sure, we had an intermediate problem with our setup a after on of our Maven repositories moved to an updated domain name which resulted in requests not being successful for some period of time, until we fixed the config.

[hboutemy]

does it mean we should close this issue as "invalid"?

[goldmann]

I would say: definitely not.

Having an incomplete manifest is not a solution. Generated manifest is not valid and never should be offered as a full manifest of a given project. It contains just a fraction of components. The warning makes it very hard to understand whether the generation was valid or in fact the output is broken.

We are very strict about our manifests. These are full or simply broken and need intervention.

[hboutemy]

ok, ok
so i need your help to better qualify how to do that: are you using the plugin from command line, or through configuration in pom.xml? Aggregate or single?

[goldmann]

We do execute it from the command line. What you see in the logs is a wrapper around the mvn CLI. Our call uses: org.cyclonedx:cyclonedx-maven-plugin:VERSION:makeAggregateBom.