cdxgen: [Gradle] Root component group and version info missing

@prabhu Just tested this out, looks brilliant, especially automating the multi project check for gradle!

As for the error you’re encountering when running the projects task on some sub-projects: elasticsearch has manually configured the list of subprojects here. However certain sub-projects don’t exist anymore (you can see that the client/transport directory was created in this PR), but their gradle config hasn’t been updated accordingly, so gradle still sees that subproject, but fails to run the task since the directory simply doesn’t exist. I would simply ignore those edge cases.

Thanks for this refactor, should simplify our workflows a bit more!

@heubeck I tested against elasticsearch last night and there were too many errors. Not sure how the older versions performed. Not sure if there are any bugs reading gradle properties to determine the sub-projects.

Thank you so much for your help. 8.5.1 released with the fixes now.

@prabhu Interesting, this is the latest sbom for java-test I could produce with this branch.

@prabhu Another small one I’ve noticed, in single project builds, the metadata.component.components is populated with the info of the root project itself. Essentially, metadata.component is replicated inside metadata.component.components. Don’t know if this is intended behaviour, but seems inaccurate. Ideally it should be empty in single project builds.

I am unable to reproduce this with java-test. Do you have an example? Can reproduce with java-test. Fix incoming for the two issues.

@ajmalab This is interesting. Shouldn’t it be application under dependencies section as well for sub-projects?

@prabhu Nop, can only find a single occurrence of pkg:application in the entire sbom. As for whether application or maven is more accurate for the root of a multi-project build, I believe it definitely should be maven according to the purl-spec (but I’m not expert on this).

@prabhu Another small one I’ve noticed, in single project builds, the metadata.component.components is populated with the info of the root project itself. Essentially, metadata.component is replicated inside metadata.component.components. Don’t know if this is intended behaviour, but seems inaccurate. Ideally it should be empty in single project builds.

@prabhu just noticed a very minor bug, in the metadata.componentseciton, the purl and bom-ref have values beginning with pkg:application rather than pkg:maven. This is still correctly shown as pkg:maven in the dependencies section though, so just the one place with the typo.

Thank you so much for confirming. Learnt a number of things about gradle in the last few days thanks to you guys. 8.5.0 is released with this new feature. Enjoy!

Hi @prabhu, apologies, I was away over the extended weekend. Will take a look by EOD today and get back to you.

@heubeck I have added a workaround to only run properties command for the first level of sub-projects. Could you kindly test the latest and let me know how it looks?

Pardon me, I’ve no real clue about gradle.

@heubeck Just like I suspected. Must be a left over from the old check which could be removed. Will let you know once I push something new tomorrow. Thank you so much for your help!

reproducer as well as real project are working now after your last changes on PR #332, @prabhu

🥇 youre the one who should be thanked

@heubeck Just like I suspected. Must be a left over from the old check which could be removed. Will let you know once I push something new tomorrow. Thank you so much for your help!

# gradle :ui-app:dependencies -q --console plain

------------------------------------------------------------
Project ':ui-app'
------------------------------------------------------------

No configurations

A web-based, searchable dependency report is available by adding the --scan option.

@heubeck, Could you also review and test PR #332 since it’s a significant rewrite to remove the GRADLE_MULTI_PROJECT_MODE env variable?

Ok, @prabhu, did some tests with PR #332 . Ordinary gradle projects work well, with and without the -r flag.

But I’ve a mixed project, that’s structured like:

build.gradle # just some plugin config, no dependencies
module1/build.gradle # java app, build config and dependencies
module2/build.gradle # no dependencies, only the plugin "com.github.node-gradle.node" configured to wrap around a node app
module2/package-lock.json
module2/package.json # the node app used to produce a react app

this projects worked fine before using -r and captured all gradle and node dependencies.

now it fails with

No packages were found in gradle project {
   name: 'module2'
...

regardless of the -r parameter.

@heubeck, Could you also review and test PR #332 since it’s a significant rewrite to remove the GRADLE_MULTI_PROJECT_MODE env variable?

oh nice. will do, give me some days.

@prabhu The gradle properties task should do the trick. The output is much more machine readable too, so you could perhaps use this to populate the project metadata section fully. It includes version, group and childProjects keys that contain the relevant info.

The task needs to be run separately for each sub-project (if any), just like the projects task with gradle :subproject1:properties to get the relevant properties.

Can use the workaround, but figured it’s worth raising an issue/feature request for future refinement!