[bug] Gradle projects where the root and at least one of the sub-projects have the same name should fail

[ajmalab]

Hello!

Currently, if the root project and one of the sub-projects have the same name, group and same/no version specified), cdxgen will ignore the sub-project and only run the dependencies tasks in the root project. This is essentially a "silent" failure, as the generated SBOM will entirely exclude dependencies from the sub-project. This is because of the way pURLs are created (group/artifact/version).

Example repo: https://github.com/ajmalab/java-test

If you look at the generated SBOM in the repo, you'll see that the com.slack.api:slack-api-client:1.45.4 which is a dependency of the sub-project with the same name is missing.

Unsure what the best solution for this would be. There are a couple of thoughts:

1. Fail when we detect duplicate pURLs. Ideally a sub-project shouldn't have the same name as the root project (even though Gradle lets you do it). Think this would be the preferred option.

2. Follow Gradle's approach: Gradle uses project paths rather than names, so the root project is simply :, sub-projects are :sub-project-a, :sub-project-b etc. Meaning the artifact name could end up being : in the pURL, which probably isn't ideal

Happy to open a PR with the solution if/when there's agreement on the approach.

[prabhu]

@malice00 any thoughts? Perhaps we add subpath to make unique purls?

[malice00]

Imo the problem of allowing duplicate artefacts is an issue with gradle. I'll look into purl regarding the subpaths, but in all honesty, I'd change my gradle configs if I were you. Are you not deploying the artefacts somewhere? I'm pretty sure a maven repo wouldn't allow this/overwrites on upload of duplicates...

[ajmalab]

@malice00 In project setups like these, the root project is not published as an artifact. This most often happens when people want the main sub-project (usually the service) artifact to have the same name as the root-project/repository. So publishing part isn't really a problem.

[malice00]

I see. I guess it would probably have a different packaging type? Or any other 'defining' features?

From the top of my head, I do believe we have both the path and purl when resolving the tree, so maybe I can use that to throw out an error. And later (or if not too complicated right away), we could add some parameters to allow this with eg a rename of one of either modules...

Do you know if there's projects that have even more clashing module names? Or is it always in sets of 2?