License Scanning doesn't handle gradle dependency constraints
Problem to solve
The following build.gradle
lists the dependency version values as constraints
using the api
directive and will result in no licenses found:
dependencies {
constraints {
api('io.reactivex.rxjava3:rxjava:3.0.4')
api('com.rabbitmq:amqp-client:5.8.0')
...
api('com.fasterxml.jackson.core:jackson-core:2.11.1')
}
}
subprojects {
dependencies {
implementation(enforcedPlatform(rootProject))
...
implementation('com.google.apis:google-api-services-gmail')
compile('io.reactivex.rxjava3:rxjava')
compile('com.rabbitmq:amqp-client')
implementation('redis.clients:jedis')
}
}
In order to fix this, the actual dependency needs to have the version
value included directly:
subprojects {
dependencies {
implementation(enforcedPlatform(rootProject))
...
implementation('com.google.apis:google-api-services-gmail')
- compile('io.reactivex.rxjava3:rxjava')
- compile('com.rabbitmq:amqp-client')
+ compile('io.reactivex.rxjava3:rxjava:3.0.4')
+ compile('com.rabbitmq:amqp-client:5.8.0')
implementation('redis.clients:jedis')
}
}
Implementation Plan
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 inheriting the version provided by a dependency constraint -
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 packages referenced using dependency constraints, add a new section entitledLimitations
to the License Compliance docs and explain the problem, as well as providing a solution (replacing a dependency constraint with an inline version value in thedependencies
block)
-
-
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 dependency constraints, 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"