Enable multiple report tasks per project

[vlsi]

Currently G-L-R stores all the configuration parameters in the project.extensions.licenseReport, thus there's no way to have two distinct reports within a single project.

Use case: one of Gradle subprojects builds artifacts (e.g. source artifacts, binary artifacts). The set of dependencies is different since "source artifact" contains "just enough sources to compile" while "binary artifact" includes runtime dependencies so the app would run.

I want to use G-L-R to collect the set of licenses, however there's no way to use two tasks within a single project.

I suggest to use project.extensions.licenseReport as defaults-only for the added license report tasks. Then developers could add their own tasks like the following:

val binaryLicenses by tasks.registering(LicenseReportTask::class) {
  projects = arrayOf(...)
  configurations = arrayOf(...)
  ...
}

val sourceLicenses by tasks.registering(LicenseReportTask::class) {
  projects = arrayOf(...)
  configurations = arrayOf(...)
  ...
}

[vlsi]

It might make sense to use Gradle's https://docs.gradle.org/current/javadoc/org/gradle/api/model/ObjectFactory.html API for task properties.

[jk1]

That would be a nice thing to implement. Thanks a lot for the suggestion.

[vlsi]

PS. Thanks for the plugin, I've implemented license management for JMeter with that.

See https://github.com/apache/jmeter/pull/448 (https://github.com/apache/jmeter/pull/448/commits/b4e2deebc8e1eb9d7debb8a7a14404e8d4e16d2a#diff-c23d70f13f973a92ceba1d72bcdd71c3R31 , however the commit id might vary over time)

However small bits like the current issue, like "one can't override license for a dependency", "the model for imported dependencies differs from auto-discovered ones" are kind of painful.

I'm inclined to implement a bit another plugin with a focus on "license file generation", "integration with SPDX", "validation of unapproved licenses". What do you think?

I'm fine if G-L-R could handle that, however I see no simple way to "add a patch" for that because it would look more like a rewrite (e.g. unification of "license" data classes for discovered and imported dependencies). I don't feel comfortable writing in Groovy either.

[jk1]

I'd say most of these issues may be addressed in the scope of the plugin. For instance, validation of unapproved licenses is something that was just merged from a pull request and released in G-L-R 1.7.

the model for imported dependencies differs from auto-discovered ones

This is something I'm looking into ATM. Should not be a big deal to fix.

integration with SPDX

Would you mind sharing your vision on how this can be of use? A couple of use cases wouldn't hurt as well.

[vlsi]

A couple of use cases wouldn't hurt as well.

1. Use license names/lists from there. There's a canonic list of licenses and license ids.
2. There's a tool that compares license file, and it can tell if the contents differs from expected one (e.g. when license starts with "apache license 2.0" and there are random changes later except copyright year)

As for me, the most important cases are: A) Generation of LICENSE files (for a given jar file or for a configuration) B) Validation if license for a dependency changes (== keep SHA512 for "approved" licenses, and fail the build if a license is not in the list) C) Ability to override license for a given artifact (e.g. one might choose a license between alternatives)

Reporting is a nice addition, however one can live without a report, however one can't release without having a proper LICENSE file.