License Scanning doesn't handle gradle subprojects
Problem to solve
If a parent project defines subprojects
with a repositories
directive:
subprojects {
dependencies {
implementation(enforcedPlatform(rootProject))
...
compile('io.reactivex.rxjava3:rxjava')
compile('com.rabbitmq:amqp-client')
implementation('redis.clients:jedis')
}
repositories {
mavenCentral()
}
}
allprojects {
repositories {
mavenCentral()
}
}
And your sub-project uses a build.gradle
which doesn't include a repositories
directive:
$ cat rabbitmq-demo/rmq-data-client/build.gradle
dependencies {
compile 'com.rabbitmq:amqp-client'
compile 'io.reactivex.rxjava3:rxjava'
}
The repositories
(and other directives) will not be inherited by sub-projects, and the build will fail. The reason this happens is that when operating recursively, license finder compiles each gradle project using only the build.gradle
file discovered in the sub-project, without considering any directives from the parent build.gradle
file. This will result in build errors, since the build.gradle
files in the sub-project will often rely on values that have been defined in the parent project, as described above.
No workaround is known at this point.
Implementation Plan
Timeboxed to ~2 days
Now that the license-finder project has been deprecated and replaced by a new method of license scanning, we need to change the implementation plan to verify that gemnasium-maven
produces the expected dependencies in the CycloneDX SBOM.
-
old implementation plan
-
Create a gradle
integration test which demonstrates the described bug. This should probably be added tospec/integration/java/gradle_spec.rb
, but this needs to be confirmed. -
Determine if the downloadLicenses
task of the License Gradle Plugin, used by license-finder, can be passed a flag to handle subprojects. Perhaps it needs to be run in the parent project and not recursively in each sub-project. -
If no such flag is available, search both open and closed issues for the License Gradle Plugin
project to see if someone else has already created an issue for this behaviour. If no such issue exists, create one. -
If no flag or workaround is available in the License Gradle Plugin
project which can handle sub-projects, add a new section entitledLimitations
to the License Compliance docs and explain the problem.
-
-
new implementation plan
-
Add a gradle
image integration test to gemnasium-maven_image_spec.rb which either demonstrates the described bug, or shows that it's not an issue. -
If the bug still exists, determine if it will be resolved by Replace gemnasium-gradle-plugin with the htmlDe... (#337083 - closed).
-
User experience goal
Current license scanning limitation is resolved or documented.
Further details
This will solve issues such as the one described in License Scanning reports no license for some complex Gradle projects
What does success look like?
License scanning should be able to display licenses for packages defined using sub-projects, or this shortcoming should be documented with a workaround provided.
What is the type of buyer?
GitLab Ultimate Enterprise Edition
Is this a cross-stage feature?
No, this only affects ~"Category:License Compliance"