generateLicenseReport fails on Gradle 9.0.0

[TeodoroFilippini]

Executing gradlew generateLicenseReport fails with Gradle 9.0.0:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateLicenseReport'.
> Resolution of the configuration ':api:runtimeClasspath' was attempted without an exclusive lock. This is unsafe and not allowed.

* Try:
> For more information, please refer to https://docs.gradle.org/9.0.0/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors in the Gradle documentation.
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to generate a Build Scan (Powered by Develocity).
> Get more help at https://help.gradle.org.

This worked on Gradle 8.14.3.

Workaround: execute the task with --no-parallel

[chadlwilson]

If you're

• using a multi-project build
• don't actually have any "stuff" on the root project
• are relying on a custom generateLicenseReport aggregate task or generateLicenseReport on specific module to put things together...

... I think it's possible to workaround this with

1. Set generateLicenseReport.enabled = false on the root project OR
2. Set licenseReport.projects = project.subprojects so there isn't a task on the root project OR
3. apply(false) on the plugin on the root project, and only apply it on subprojects.

[bdellegrazie]

@chadlwilson / @jk1 we may need to consider splitting behaviour between a report aggregation task and report "data" generation task. As an example, this is similar to the cyclonedx plugin.
At the moment I think this is the primary blocker for clients wanting to use this with Gradle 9 when the workarounds above don't work.

[ghenadiibatalski]

Hi everyone, the workaround with --no-parallel is fine, but it doesn't seem like the configuration can be done via a property for this particular task. So we need a working solution. Regards, Gena

[chadlwilson]

Did you try with the workarounds I posted aside from that? Those can be done with configuration.

[ghenadiibatalski]

Did you try with the workarounds I posted aside from that? Those can be done with configuration.

@chadlwilson it doesn't work out of the box. I need a more complex change on configuration to meet my requirements. But if the current setup did work fine on gradle <9 , i think, it should also work in a future :-)
Regards, Gena

[chadlwilson]

You said you wanted a working configuration-oriented solution (without Gradle args) and so I gave one. Now you're saying you want something different, the same as the original issue?

No-one disagrees that it would be better if it was natively supported, but unless you're willing to help contribute I'm not quite sure when the goal of your message is.

The deprecation warning messages that caused this to break on Gradle 9 have been there for years in both Gradle 7 & 8 (see #225) without anyone helping to address, so what the project needs is clearly 'help' rather than 'me too' requests.

[ghenadiibatalski]

@chadlwilson I understand, but the workarounds don't work without complex configuration changes. I'm not familiar with the plugin's exact functionality or its integration into our CI/CD pipeline. Therefore, I wouldn't change anything unless absolutely necessary. Furthermore, the license report isn't one of my primary responsibilities, so I wanted to inform you about the issue. The main reason for my comment is that it works with version 2.9 of the plugin itself, using Gradle 9.2.0 and Java 25, without any configuration changes, but it no longer works with version 3.0.1. I thought this information might be of interest.
Best regards, Gena

[chadlwilson]

I understand, but the workarounds don't work without complex configuration changes. I'm not familiar with the plugin's exact functionality or its integration into our CI/CD pipeline. Therefore, I wouldn't change anything unless absolutely necessary.

If you don't expect config changes, and are not familiar with your plugins you probably shouldn't be doing major Gradle version upgrades and should be sticking on 8.x.

The major version increment means they broke both plugins and user behaviour, and thus both are likely to need change to accommodate.

The main reason for my comment is that it works with version 2.9 of the plugin itself, using Gradle 9.2.0 and Java 25, without any configuration changes, but it no longer works with version 3.0.1.

You didn't mention anything about 3.x earlier? Sigh.

Do you have a reproducer project? Unless you provide an example of a project that worked on 2.9 but now doesn't on 3.x along with errors I'm not sure what anyone can do to address this.

I don't see a reason anything should start failing after 2.9 -> 3.0 with the above error unless it's to do with the allowedLicensesFile now being properly tracked as an input, causing your tasks to order differently and thus something specific to how your tasks are defined or some hack you had there earlier. Again, if you want to help we'd need an example project or fuller description of how to reproduce the issue.

[ghenadiibatalski]

Sorry @chadlwilson , you are right!

1. The behavior is identical in versions 2.9 and 3.0.x. Locally, both fail with Gradle 9.2.0, but work perfectly with Gradle 8.14 (tested with simple gradle spring boot project with only one subproject).
2. I was misled by another problem on the CI/CD pipeline (parallel processing apparently doesn't work there): The syntax allowedLicensesFile = new URL('https://<myurl>/allowed-licenses.json') no longer works. However, the local investigation of the problem stumbled upon parallel processing. Regards, Gena

 What went wrong:
Execution failed for task ':checkLicense'.
> Cannot convert the provided notation to a File: https://<myurl>/allowed-licenses.json.
  The following types/formats are supported:
    - A String or CharSequence path, for example 'src/main/java' or '/usr/include'.
    - A String or CharSequence URI, for example 'file:/usr/include'.
    - A File instance.
    - A Path instance.
    - A Directory instance.
    - A RegularFile instance.
    - A URI or URL instance of file.
    - A TextResource instance.

[chadlwilson]

2. I was misled by another problem on the CI/CD pipeline (parallel processing apparently doesn't work there): The syntax allowedLicensesFile = new URL('https://<myurl>/allowed-licenses.json') no longer works. However, the local investigation of the problem stumbled upon parallel processing. Regards, Gena

 What went wrong:
Execution failed for task ':checkLicense'.
> Cannot convert the provided notation to a File: https://<myurl>/allowed-licenses.json.
  The following types/formats are supported:
    - A String or CharSequence path, for example 'src/main/java' or '/usr/include'.
    - A String or CharSequence URI, for example 'file:/usr/include'.
    - A File instance.
    - A Path instance.
    - A Directory instance.
    - A RegularFile instance.
    - A URI or URL instance of file.
    - A TextResource instance.

Yes, that is due to #260 and is probably part of the reason for a 3.x semver change.

As the error message broadly suggests, changing it to one of = ’https://<myurl>/allowed-licenses.json' or = new File(URI.create('https://<myurl>/allowed-licenses.json')) will probably work.

[ghenadiibatalski]

@chadlwilson new File(URI.create(.. results in

A problem occurred evaluating root project 'demo'.
> URI scheme is not "file" 

[chadlwilson]

Then try and create a file from a URL, or use aTextResource from a URL.

This is completely off topic anyway - open a separate issue if you can't figure it out after reading Gradle documentation and trying various combinations. It's giving you all the options in the error message already.

[ghenadiibatalski]

Then try and create a file from a URL, or use aTextResource from a URL.

This is completely off topic anyway - open a separate issue if you can't figure it out after reading Gradle documentation and trying various combinations. It's giving you all the options in the error message already.

Yes, this is off topic but also causes the plugin to not to work . I think, the problematic change is here: 40658b4 , so either the documentation is wrong or the coding.