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

  1. Create a gradle integration test which demonstrates the described bug. This should probably be added to spec/integration/java/gradle_spec.rb, but this needs to be confirmed.
  2. 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
  3. 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.
  4. 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 entitled Limitations 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 the dependencies block)

• new implementation plan

  1. 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.
  2. 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"

/cc @gonzoyumo @NicoleSchwartz