Reporter: add support for deduplicateDependencyTree for CycloneDX, SPDXDocument report formats

[Etsija]

What is the existing functionality and how should it be enhanced?

Currently, only EvaluatedModel and WebApp reporters support the deduplicateDependencyTree option.

What is the use-case for your enhancement?

We have had Java heap space issues with the Reporter, trying to create WebApp, CycloneDX and SPDXDocument reports for a big Gradle project (after running Analyzer, Scanner and Evaluator successfully). Have tried to allocate up to 20GB memory for Java, with no success. Trying to run the Reporter for the project has actually several times crashed my power laptop running Ubuntu 24.04.

Today I found the discussion #9875 and decided to try out deduplicateDependencyTree option for the WebApp reporter. Result: it took only some 30 seconds to produce a working WebApp for my "problem project", without any memory issues. However, trying to produce CycloneDX and SPDXDocument reports still fails due to out-of-memory / Java heap space issue.

I think implementing similar support for deduplicateDependencyTree for at least CycloneDX and SPDXDocument - if not globally to all reporters - would possibly alleviate the memory problems for big Gradle projects.

Additional context

Issue which is possibly related: #9763.

[mnonnenmacher]

I think implementing similar support for deduplicateDependencyTree for at least CycloneDX and SPDXDocument - if not globally to all reporters - would possibly alleviate the memory problems for big Gradle projects.

If this feature is now required for more report formats I would be in favor of making it a global option. But we would have to check first if there are any reporters that should NOT support this option.

[fviernau]

For the SBOM formats, maybe also a "flatten" dependency tree option could make sense, where all packages become direkt dependencies of the project. Would this also work around your issue @Etsija ?

[Etsija]

For the SBOM formats, maybe also a "flatten" dependency tree option could make sense, where all packages become direkt dependencies of the project. Would this also work around your issue @Etsija ?

I think @sschuberth is far more of an expert to answer to that, tbh.

[fviernau]

I think @sschuberth is far more of an expert to answer to that, tbh.

Well, my ask was specifically whether that'd fullfill your requirements, @Etsija

[Etsija]

I'm in no position to answer that; I'm merely doing technical onboarding for a customer at the moment, but I'm a developer, in no way an expert of SBOMs - that's why I referred to Sebastian, as he's my manager and gave me this task.

But I got information from our team that at the moment, this customer doesn't require a full fledged SBOM, a notice file is sufficient for them for now.

[fviernau]

as he's my manager and gave me this task.

Wasn't aware of that. So, nevermind.

[sschuberth]

For the SBOM formats, maybe also a "flatten" dependency tree option could make sense, where all packages become direkt dependencies of the project. Would this also work around your issue @Etsija ?

Actually, by default most SBOMs formats restrict themselves to a "flat list of dependencies" anyway, and having a dependency graph / hierarchy / relationships is optional, see e.g. #3906 for CycloneDX.

So instead of having a "flatten" dependency tree option, we should probably have options to turn off the optional generation of graphs (CycloneDX) / relationships (SPDX).

[fviernau]

So instead of having a "flatten" dependency tree option, we should probably have options to turn off the optional generation of graphs (CycloneDX) / relationships (SPDX).

So, what is the difference besides naming it differently?

[sschuberth]

So instead of having a "flatten" dependency tree option, we should probably have options to turn off the optional generation of graphs (CycloneDX) / relationships (SPDX).

So, what is the difference besides naming it differently?

Well, let me try to explain it again differently: There is no point in having a "flatten" dependency tree option as the list already is flat. So instead of adding code to actively flatten something, we'd just need to add code to omit an optional graph. Implementation-wise that makes things simpler.