I want to add several functionalities into this repo, but want to listen about your opinions first.

[XenoAmess]

functionality 1 : enforce same dependency version in repo
Search from components, find all components with same group and name, but different version .If found any then fail. Otherwise succeed.
Might have an additional exclude mechanism
functionality 2 : enforce same dependency version as from one input sbom file.
functionality 3 : enforce license of components (blacklist and whitelist)

I see your codes, and seems I can do these codings myself. But I'm not sure:

1. may these functionalities merged into this repo? or I have to start another plugin repo?
2. should these functionalities be mojo, or be configurations inside of existing mojos? if you think it better to add mojos, should I add several seperate mojos, or 1 mojo with different configurations?

[ThomGeG]

I'm not one of the maintainers, just a guy with often annoying opinions, but would an entirely separate tool be more appropriate?

The way I see the maven plugin itself is just as a means to generate the BOMs and then any kind of post-processing/usage of those BOMs should be done outside it with other tools (like with Dependency-Track or the CycloneDX-CLI). The biggest boon to doing it that way would be that although there's an extra step in running the checks, you're now doing so in an agnostic way and would get better reuse and support from the rest of the community who might be using Python, .NET, Node, etc. instead.

The CLI tool's analyze command seems to already be capable of doing some introspection about duplicate components, building on it in some way would probably be the better long-term solution.

[XenoAmess]

The way I see the maven plugin itself is just as a means to generate the BOMs and then any kind of post-processing/usage of those BOMs should be done outside it with other tools (like with Dependency-Track or the CycloneDX-CLI). The biggest boon to doing it that way would be that although there's an extra step in running the checks, you're now doing so in an agnostic way and would get better reuse and support from the rest of the community who might be using Python, .NET, Node, etc. instead.

The CLI tool's analyze command seems to already be capable of doing some introspection about duplicate components, building on it in some way would probably be the better long-term solution.

Well I add these functionalities for generating/verify sbom in gitlab runner ci.
Your suggestions sounds reasonable, but that means I must modify the image used in the ci runner(to install a CycloneDX-CLI and even dotnet runtime), which is what I actually have no privilidge to do.

[stevespringett]

There are three algorithms for merging and implementing each one in all the various tools is a tremendous amount of work. For the time being, the CycloneDX CLI is the only way that implements these merging algorithms. I would also like to implement this logic in CycloneDX Core Java and make it available to the Maven and Gradle plugins in the future. If anyone wants to tackle this, PRs are accepted.