Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot change usage of dependency configuration 'xxx' after it has been included in dependency resolution. #338

Open
sergeys-opera opened this issue Aug 3, 2023 · 5 comments

Comments

@sergeys-opera
Copy link
Contributor

The plugin spits a lot of warnings while running its licenseDebugReport task:

Task :ui:licenseDebugReport
Cannot resolve configuration androidTestAnnotationProcessor
org.gradle.api.InvalidUserDataException: Cannot change usage of dependency configuration ':ui:androidTestAnnotationProcessor' after it has been included in dependency resolution.
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.preventIllegalMutation(DefaultConfiguration.java:1551)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.validateMutation(DefaultConfiguration.java:1510)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.setCanBeResolved(DefaultConfiguration.java:1880)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.setCanBeResolved(Unknown Source)
	at com.jaredsburrows.license.LicenseReportTask.setupEnvironment(LicenseReportTask.kt:161)
	at com.jaredsburrows.license.LicenseReportTask.licenseReport(LicenseReportTask.kt:97)
... a lot more

Some warnings contain a slightly different error message:

Cannot resolve configuration testFixturesRuntimeOnly
org.gradle.api.GradleException: Cannot change the allowed usage of configuration ':ui:testFixturesRuntimeOnly', as it has been locked.

AGP version: 8.1.0
Plugin version: 0.9.3

@t-beckmann
Copy link
Contributor

@jaredsburrows
Copy link
Owner

Is this the same as #234? Also, why is configuration.isCanBeResolved = true not necessary?

@sergeys-opera
Copy link
Contributor Author

Is this the same as #234?

Probably, yes.

My workaround for this issue is:

    // Silence excessive warning messages from "license[Debug|Release]Report" task,
    // see https://github.com/jaredsburrows/gradle-license-plugin/issues/338
    forEachTask(predicate = { it.name == "license${variantName}Report" }) {
        it.notCompatibleWithConfigurationCache("Not implemented")
        (it.logger as ContextAwareTaskLogger).setMessageRewriter { logLevel, message ->
            if (logLevel == LogLevel.WARN && message.startsWith(
                    "Cannot resolve configuration"
                )
            ) null else message
        }
    }

I couldn't get rid of the error messages by using mustRunAfter/dependsOn as suggested in #234. The project where I see the issue is an Android project if that matters.
I also call notCompatibleWithConfigurationCache on the license task as it's not yet (version 0.9.4) compatible with the configuration cache.

@jaredsburrows
Copy link
Owner

I have had this plugin applied to a project of mine - https://github.com/jaredsburrows/android-gif-search. It has now been migrated to ksp instead of kapt / annotationProcessor. I have not been able to reproduce this.

I can look into removing these warnings produced by the plugin scanning the configurations.

@t-beckmann
Copy link
Contributor

For those interested, the meaning of those flags is discussed at https://docs.gradle.org/7.5.1/userguide/declaring_dependencies.html#sec:resolvable-consumable-configs.

Setting the isCanBeResolved turns producer and internal configurations to consumers. In the project I am working on doing so has unexpected side-effects on the Gradle build cache, so that it no longer matches!

Admittedly I do not fully understand the effect on the build cache, but I could resolve it by running the license plugin in a separate Gradle invocation separate from all other tasks. My guess is changing isCanBeResolved leads to a different order of dependencies in other configurations...

I am saying changing the flag should not be necessary because a configuration that is not resolvable contributes files to the build only if it is resolved indirectly via some other configuration extending upon it. But in that case the files in question are part of the extending configuration as well and so are picked up by the license plugin nevertheless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants