GRADLE_ARGS partially ignored in recursive mode

[heubeck]

Having a multi-module gradle project with GRALDE_ARGS set, these are not applied to every gradle call executed:

# export GRADLE_ARGS="-PartifactoryUser=*ARTIFACTORY_USER* -PartifactoryPassword=*ARTIFACTORY_PASSWORD*"
# cdxgen ...

Executing /home/heubeck/w/sbom-test/branded-services-support/gradlew properties -q --console plain --build-cache in .
Executing /home/heubeck/w/sbom-test/branded-services-support/gradlew :ui-app:properties -q --console plain --build-cache in .
Executing /home/heubeck/w/sbom-test/branded-services-support/gradlew :ui-server:properties -q --console plain --build-cache in .
Executing /home/heubeck/w/sbom-test/branded-services-support/gradlew :ui-app:dependencies -q --console plain --build-cache -PartifactoryUser=*ARTIFACTORY_USER* -PartifactoryPassword=*ARTIFACTORY_PASSWORD* in .
Executing /home/heubeck/w/sbom-test/branded-services-support/gradlew :ui-server:dependencies -q --console plain --build-cache -PartifactoryUser=*ARTIFACTORY_USER* -PartifactoryPassword=*ARTIFACTORY_PASSWORD* in .

[prabhu]

@heubeck, does the gradle properties command support GRADLE_ARGS?
@malice00, any thoughts on bringing back this functionality? Below is the PR that removed this variable.

https://github.com/CycloneDX/cdxgen/pull/385/files

[heubeck]

does the gradle properties command support GRADLE_ARGS?

I've no idea, just recognized that I cannot add options like -p to address modules within a project.

any thoughts on bringing back this functionality? Below is the PR that removed this variable.

🤯

[prabhu]

does the gradle properties command support GRADLE_ARGS?

I've no idea, just recognized that I cannot add options like -p to address modules within a project.

any thoughts on bringing back this functionality? Below is the PR that removed this variable.

exploding_head

Put it the other way, is there an issue with the current behaviour like sbom having less components or dependency etc?

[heubeck]

Put it the other way, is there an issue with the current behaviour like sbom having less components or dependency etc?

there's a multi-module gradle project, for which I have to start cdxgen in the project root folder, but have to address single modules using -p some-subodule which isn't propagated to the gradle properties command, but to gradle dependencies.
not quite sure, how much of a problem it is by now, just recognized the inconsistency.

[heubeck]

ok, did some comparison.

the dependency components are equal: taken from the submodul I gave with GRADLE_ARGS="-p sumodule".
but the metadata.component information refers to the root project instead of the subproject (obvious because properties is called for that).

Not quite sure, if there are cases with project properites like -Psomething=need could be relevant for gralde properties - but having no option at all to configure it feels wrong.

[prabhu]

@heubeck any chance you can contribute a test project to replicate this?

[heubeck]

@heubeck any chance you can contribute a test project to replicate this?

will do.

[malice00]

Sorry for the late reply.

I had issues with the GRADLE_ARGS being added to both Gradle-calls in the code (properties and depdencies) where only the latter understood the added arguments. Even worse, the call to 'properties' failed because of unknown arguments!

I can understand you wanting to have GRADLE_ARGS back, but maybe we should have 2 versions of it, eg:

• GRADLE_ARGS_PROPERTIES
• GRADLE_ARGS_DEPENDENCIES

That way, it you can even set different arguments for either call!

Or mavbe even go the extra mile and make 3 EnvVars, where the documentation than clearly explains that 'GRADLE_ARGS' is used for both calls, but the above are for the specific calls?

[prabhu]

@malice00 I am happy with the proposed 3 env variable approach. Would it be possible to send a PR?

[malice00]

It seems somebody already did! :-) Thanks @heubeck!