License Scanning doesn't handle gradle subprojects

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Collaborate/take over this issue

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

  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 subprojects. Perhaps it needs to be run in the parent project and not recursively in each sub-project.
  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 sub-projects, add a new section entitled Limitations to the License Compliance docs and explain the problem.

• 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 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"

/cc @gonzoyumo @NicoleSchwartz