CycloneDX / CycloneDX/cyclonedx-maven-plugin
What if a Maven module produces multiple variants?
- Dominant language
- Java
- Stars
- 385
- Forks
- 107
- Avg merge
- 17h 31m
- Merged PRs (30d)
- 7
Description
How should we deal with the scenario where a maven module produces several types of output, for example both a 'regular' jar (with regular dependencies) and a 'fat' jar (with some of the dependencies embedded into the jar)?
This question came up in https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/472#issuecomment-2439884740. This situation can be found for example in https://repo1.maven.org/maven2/org/apache/pekko/pekko-grpc-codegen_3/1.1.0/ : it has both the `-assembly.jar` and a regular `.jar`.
I'd say the main choice is between describing both the 'regular' and the 'fat' artifact in one SBOM, or to creating separate SBOMs for each artifact.
From the perspective of "how are SBOMs used?", I think there are typically two classes of consumers of SBOMs for a project: the maintainers of the project themselves, and users who have the project somewhere in the dependency tree of their systems. The latter category will probably start from a particular artifact that they encounter on their systems, and be interested in specifically the SBOM for that artifact. So I think they would prefer it if there were a separate SBOM for each artifact. For the maintainers of the project I could see use cases where they'd like to analyze the combined metadata for all their artifacts, but for that I don't see a particularly strong preference for 'one big SBOM' over 'SBOM per artifact'.
So overall I think it'd make most sense to have a separate SBOM per artifact - i.e. for https://repo1.maven.org/maven2/org/apache/pekko/pekko-grpc-codegen_3/1.1.0/ generate both a `pekko-grpc-codegen_3-1.1.0-cyclonedx.json` and a `pekko-grpc-codegen_3-1.1.0-assembly-cyclonedx.json`.
Contributor guide
Research direction
No source files, tests, or entry points are named. Start by examining how the Maven plugin discovers and generates SBOMs for artifacts, using the regular and `-assembly.jar` examples in the issue; done should produce a separate CycloneDX SBOM for each artifact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100