Open lonewalker0 opened 1 week ago
I would like to ask if this expected behaviour would also differentiate the submodules and the external dependencies in case no projectType is defined for the configuraion of the plugin, as the SBOM aggregation process should have a way of categorizing both (it may not be using type
though) and reflecting this distinction in every component/dependency in the final SBOM.
If the intention of this parameter is purely providing a configuration set by users when executing the plugin (only for submodules), then I think we could benefit from some parameter that also identifies every component in the way I described.
If the project type in the submodules has not been set, then the default behavior is to consider them as 'library'. Regarding the addition of another parameter, I didn't understand what you mean.
Description
In a multimodule Maven project, some submodules are configured with the projectType: application setting in the CycloneDX Maven plugin. However, when generating the aggregated SBOM (Software Bill of Materials), these submodules still have the component type set to "library" by default. This behavior results in an incorrect component type assignment for those submodules.
Steps to reproduce:
Create a multimodule Maven project. Configure the CycloneDX Maven plugin in the parent POM. In one of the submodules, set the projectType configuration to application. Generate the aggregated SBOM using the CycloneDX Maven plugin.
Expected behavior:
The aggregated SBOM should reflect the correct component type for each submodule based on their individual projectType configurations. Submodules configured as application should have their component type set to application.
Actual behavior:
Submodules configured with projectType: application still have their component type set to library in the aggregated SBOM.
I also have a solution to address this issue.