Deprecation Warnings

[joshovi]

Hi,

I am new to the license report plugin. I get warnings like The configuration :com.mycompany:runtimeClasspath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a thread not managed by Gradle or from a different project. See https://docs.gradle.org/5.6.2/userguide/troubleshooting_dependency_resolution.html#sub:configuration_resolution_constraints for more details. This behaviour has been deprecated and is scheduled to be removed in Gradle 6.0.

Is this a mistake on my part? Or is it intrinsic to the plugin?

[marques-work]

@jk1 deprecations such as these as well as #181 will break in the next major Gradle release. I don't mind helping out with a PR -- but maybe could you point me in the right direction of where to look for some of these? It may otherwise take me some time to get familiar with the code and how everything works.

[jk1]

@marques-work I'd appreciate that. Will try to take a closer look into it this week.

[danilovesky]

@jk1 and @marques-work Did you manage to tackle the deprecation issues? I would also like to help, if possible. These warnings become quite pressing as Gradle 7 is not far away now..

Here is a couple more examples to help and pinpoint the use of deprecated API:

Property 'config.cache.$1.onlyOneLicensePerModuleCahce' is private and annotated with @Input. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.
...
The compileOnly configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.7/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
...
The runtime configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the runtimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.7/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
...

And a screenshot from Gradle Scan service (in case it is of any use):

[jk1]

Hi all,

Thank you for your patience.

As there are several distinct groups of warnings mentioned here it may be tricky to address them all in one go. For a start, there's 1.16 now with warnings from #181 fixed.

The compileOnly configuration has been deprecated for resolution.

The problem with this one is that the plugin doesn't rely on the said configuration anyhow. What the plugin does, it resolves configurations is has been said to resolve:

licenseReport {
    configurations = ['compile']
}

So if your project relies on the compile configuration when declaring its dependencies, it's not compatible with the upcoming Gradle 7.0 by itself.

As I wasn't able to reproduce this warning with projects I'm using the plugin in myself, it'd help a lot if someone could provide a minimum project, that emits the warning. It would help us all to understand if this is a configuration only issue, or there's more to it to be fixed in the plugin.

The configuration :com.mycompany:runtimeClasspath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a thread not managed by Gradle or from a different project.

What I can say for sure, is that there're only Gradle-managed threads used in there. So we can safely rule the threading issue out.

It may still be related to the way the project is structured. There's a nice example of such an issue described in https://stackoverflow.com/questions/54167909/copy-gradle-dependencies-from-another-subproject-without-deprecation-warning. One way or another, a minimal project, that is able to emit the warning will be invaluable for further analysis.

[marques-work]

@jk1 I think so long as this plugin doesn't get the compileOnly for resolution error, it's fine; as you said, that's likely to do with the project applying this plugin.

FWIW, a text search of this repo reveals no results for compileOnly. So any errors reported must be from a user's project, not here.

Thanks for the 1.16 release!

[marques-work]

@jk1 ~I just upgraded my build to use 1.16 and I now see zero Gradle 7.0 deprecation messages (with --warning-mode all, running gradle 6.6.1). This should confirm that any such dependency configuration warnings are not from this plugin.~

I spoke too soon :). I am seeing warnings about configurations being accessed in an unsafe manner. But nothing about using configs deprecated for resolution.

[danilovesky]

@jk1 Thank you, half of deprecation messages are gone now!

Could you advise how to correctly configure a multi-project build to check the licenses for all sub-projects please? I probably have insufficient understanding of Gradle and miss something important when following these instructions: https://github.com/jk1/Gradle-License-Report#configuration

Currently my gradle.buld has a section (in an attempt to catch all compile-time and run-time dependencies):

apply plugin: 'com.github.jk1.dependency-license-report'
licenseReport {
    configurations = ['runtimeClasspath', 'compileClasspath']
    renderers = [new com.github.jk1.license.render.InventoryHtmlReportRenderer()]
    allowedLicensesFile = new File("${project.rootDir}/config/license/allowed.json")
}

This results in warnings about deprecation of both compileOnly and runtime configurations (as in the above https://github.com/jk1/Gradle-License-Report/issues/161#issuecomment-711855044).

If I change it to configurations = ['compile'] (as per README.md example) I still get a warning:

The compile configuration has been deprecated for resolution

If I remove that configuration=... line completely, then (as far as I understand) the default runtimeClasspath configuration is used and warning is as fallows:

The runtime configuration has been deprecated for resolution.

I experience these issues in a (rather large) project Workcraft. If there is no obvious mistake that you can easily point to then I will try to scale it down and reproduce in a minimal multi-project.

[frankk3]

I also see these

The runtime configuration has been deprecated for resolution.

Gradle 7.0 deprecation warnings in my projects that apply gradle-license-report version 1.16.

From my point of view, com.github.jk1.license.reader.ProjectReader.findConfiguredConfigurations(...) returns correctly only the configured configuration as configurationsToScan, i.e. usually runtimeClasspath per default, but getAllExtendedConfigurations(Collection<Configuration> configurationsToScan) looks up all configurations which this runtimeClasspath configuration extends from, i.e.

• runtimeOnly,
• runtime and
• implementation

and returns the resolvable ones, i.e. runtime.

In line 48, it is added to configurationsToScan.

Therefore, not only the original runtimeClasspath configuration is resolved by the plugin later on, but also runtime, which results in that Gradle 7.0 deprecation warning.

What's your opinion about that?

[frankk3]

I've just created a minimal Gradle 6.5.1 project to illustrate that: RuntimeConfigDeprecatedForRes-Gradle7.tar.gz

Note: Instead of applying Gradle's java plugin, its successor java-library can be applied instead, which has the same effect.

[MartinHaeusler]

I just bumped into this warning as well. I've tried a myriad of different combinations now (gradle "configurations" are mysterious beings, really...) but all of them either fail or give me the deprecation warning about depending on a sub-project's configuration imporperly.

Did anybody find an actual solution to this?

[AndreyNudko]

I think configuration was resolved without accessing the project in a safe manner may be a threading problem after all

In our project ./gradlew cleanGenerateLicenseReport generateLicenseReport --warning-mode=all --stacktrace --no-parallel generates only a few warnings about input/output annotations; --parallel adds about 15000 more (literally) of those errors.

Here's a partial stack-trace:

The configuration :xml-pre-processor:testRuntimeClasspath was resolved without accessing the project in a safe manner.  This may happen when a configuration is resolved from a different 
project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.8.3/userguide/viewing_debugging_dependencies.html#sub:resolving-un
safe-configuration-resolution-errors for more details.
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveToStateOrLater(DefaultConfiguration.java:594)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getResolvedConfiguration(DefaultConfiguration.java:573)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getResolvedConfiguration(Unknown Source)

Here's the code in question (slightly different version than ours but close enough): https://github.com/gradle/gradle/blob/29d268a7a7bed5275b9ed9ed0441778c6ee68fe4/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/configurations/DefaultConfiguration.java#L594

My best guess is that sub-project is owned and possibly mutated in another thread when being accessed from the task - but I'm no expert in how gradle works.