Open marcelstoer opened 1 year ago
cyclonedx-maven-plugin
consumes data from effective Maven model of your dependencies: if your dependencies have wrong effective model, the fix has to happen in the dependency
=> please open an issue to the dependency project, and even a PR to help them fix their bug
I don't see what cyclonedx-maven-plugin
can do, it's just showing an existing bug in the dependency: any idea what we can reasonably do (without too much hack) at cyclonedx-maven-plugin
?
cyclonedx-maven-plugin consumes data from effective Maven model of your dependencies
Ok, good to know, thanks.
any idea what we can reasonably do
If you're referring to the effective model then, no, I guess you can't do anything.
I don't know if the current behavior for the effective model is intended or not. Hence, the project team might not even see it as a bug. In the context of CDX, however, it's just wrong to display the description as-is. The only option I currently see is for the cyclonedx-maven-plugin to not pull the component description from the effective model but from the component's actual POM.
I don't know if the current behavior for the effective model is intended or not
it is, it's what POM inheritance is all about, part of "Getting Started": https://maven.apache.org/guides/introduction/introduction-to-the-pom.html
In the context of CDX, however, it's just wrong to display the description as-is.
the thermometer shows you a fact: if the fact is a problem, you'll need to fix the problem, no say that the thermometer has to be fixed
The only option I currently see is for the cyclonedx-maven-plugin to not pull the component description from the effective model but from the component's actual POM.
that approach is not reasonable, sorry: many project enhanced their description when necessary, and chose to keep inherited value when it makes sense
one option I see is that we could perhaps add in cyclonedx-maven-plugin
a ignoreDescription
parameter that you could configure to define which description you prefer to ignore in your SBOM, because you think it's a bug from your dependencies and you prefer no description than buggy one. Does it seem ok to you?
many project enhanced their description when necessary, and chose to keep inherited value when it makes sense
š I wish it was such a conscious decision all the time.
In my experience, more often than not developers simply "forget" to describe their component as the POM <description>
is an optional element. Sure, sometimes it's laziness rather than forgetfulness.
My 'public example' above is a very representative for what I'm seeing usually - both with our own modules and public ones. I am quite certain the swagger-api/swagger-core project team never intended for their modules to be advertised as "Sonatype helps open source projects to set up Maven..." š.
you prefer no description than buggy one
Absolutely, that's the primary goal. Giving me an option to turn off component descriptions would certainly be welcome.
Giving me an option to turn off component descriptions would certainly be welcome.
you mean a basic boolean?
Yes, would be useful IMO. Once released I could then raise a PR with the cdxgen project to support a new env variable for the Maven plugin (similar to CDX_MAVEN_INCLUDE_TEST_SCOPE
).
Component descriptions (bom/components/component/description) seem to be inherited. This leads to completely wrong descriptions when a particular Maven module has none. Example:
In the CDX the "project module" component will have a
<description>
of "I'm the parent of all" which is confusing at best.I am expecting for "project module" to have no description at all as it is also missing in its POM.
Public example