Forbid dependency resolution at configuration time by default #2298
Comments
|
@oehme I think this should be reconsidered for 5.0 given that the Kotlin team messed up too: https://youtrack.jetbrains.com/issue/KT-26065. |
|
Has this been implemented? I'm seeing a user who let me know they're seeing an error now:
Is there a separate issue tracking the implementation of this feature which has been completed? |
|
I'm not aware of such a change, I suspect a plugin is doing this. |
|
@melix Heres the issue that caused me to ask this question, apparently the Android plugin is doing this audit now. |
|
i reported a usage scenario that seems to require early dependency resolution to get any semblance of cleanliness in the code. it's here. or maybe there is something i haven't thought of? thanks! |
|
I'm getting it with gradle 5.4 and AGP 3.4.0-rc2. It looks like it comes from the Android plugin: Do you have direct contact with Google android team? |
|
There's no way to disable this check from Gradle, this is done in the Android Plugin. I don't think there are a lot of use cases, if any, that require resolution at configuration time. In most cases deferring by using a closure would be enough. |
|
I assume it is connected with usage of gradle 5.4 since the same Android plugin works fine on gradle 5.3 |
|
Note that that stacktrace is not a failure, but a warning with stacktrace logged at info, see the line number - turning --info off will lead to the warning not being generate. Sounds like we (the Android Gradle Plugin team) need to update this check for changes in Gradle 5.4, but other than the noise it should not affect the build. |
|
Thanks, I have build failed and log is cut on CI and this last messeges, so I intepreted them as a cause but it is not. Thank you again! |
|
For some of my projects #9150 is the primary cause of eager dependency resolution. If that is fixed my dependency resolution is happily working at execution time. I think making this default behavior proposed here is the way to eradicate this problem even from Gradle core itself. |
|
|
|
I use |
|
Hi, I got these warnings after upgrading AGP 7.1.2 to 7.4.1 After checking, the code that trigger this is a dependency substitution rules in our plugin, something like this: project.configurations.configureEach {
resolutionStrategy.dependencySubstitution {
modulesToBeSubstituted.forEach { A ->
substitute(module(A)).using(project(A))
}
}
}And checking the AGP code to avoid this warning we need to resolve it after task graph is ready. After wrapping the code above in Questions:
Thank you |
|
I am getting this warning in my Android application project. How can I fix this? $ ./gradlew clean aCcc36c3Debug --stacktrace --info
...
> Configure project :network
Evaluating project ':network' using build file 'EventFahrplan/network/build.gradle'.
Using default execution profile
Using Kotlin Gradle Plugin gradle76 variant
Task name matched 'clean'
Abbreviated task name 'aCcc36c3Debug' matched 'assembleCcc36c3Debug'
Selected primary task 'clean' from project :
Selected primary task 'aCcc36c3Debug' from project :
Configuration 'kspCcc36c3DebugKotlinProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
java.lang.RuntimeException: Configuration 'kspCcc36c3DebugKotlinProcessorClasspath' was resolved during configuration time. |
Actually, this is not true. The change introduced a subtle bug that we decided to revert the change. For the warning message since it's annoying and making devs hard to read the console, we monkey-patched AGP to remove it. |
|
I just upgraded to Android Studio 2022.1 patch 2 and upgraded gradle to version 7.5.1. When I rebuilt my project in this new environment I got the following message: Configuration 'mavenResource' was resolved during configuration time. here's the relevant portions of what my build.gradle.kts file looks like: val mavenResource = configurations.create("mavenResource") dependencies { So that is what appears to me to be what causing this message about the performance and scalability issue that's what got me to this discussion. So "oehme" makes the claim that there is no reason for someone to have a configuration resolved at configuration time. In most situations that's probably true, but there are reasons for doing that. In my case, I add the configuration named "mavenResource". In the dependencies block I add any number of "mavenResource" dependencies. My project also applies a custom plugin that finds the mavenResource configuration and then copies all the files for those resolved dependencies to the projects "resources" directory. It's a very simply handy way to add resources to my project where the resources are stored in a maven repository. My actual dependencies are specified in a toml version file. So if I change the version of a given resource in the toml version file, my project when rebuilt gets the right version of the resource. I claim that's a legitimate use of a configuration time dependency resolution. I'm taking advantage of gradle's mechanism for getting dependency from a repository, not for code library, but for resource objects. What's neat is that it only takes a couple lines of code in a custom plugin to take advantage of this. By disabling this feature, I don't think I have such a nice elegant solution. Also, when you put together JavaDoc documents, one often needs to add a "javaDoc" configuration so that you can add some additional dependencies for the JavaDoc task. I believe that too, would cause this same warning. |
|
I believe, according to the current Gradle best practices it should all be done in a lazy manner. That is, the plugin can still scan all As I understand it, the main motivation behind this restriction is, that you don't need to perform time-consuming operations that are not essential for the build logic itself, but only for the application code. |
|
One use case is that I want to quicky see what jar's my classpath resolves to. Previously I could just do hack |
|
The same, but wrapped in |
|
Any Update on This Issue has it been Resolved by anyone yet? I am Facing this in Circle CI
|
|
I have some code that resolves configurations and collects data on which dependencies are used by which others. I do this for every configuration that is marked as It has always worked perfectly fine, apart from the AGP yelling at me to stop resolving configurations at configuration time. So I finally listened, and attempted to do it all in a task execution. I basically just have this: abstract class InspectConfiguration: DefaultTask() {
@InputFiles
var configuration: Configuration? = null
@TaskAction
fun execute() {}
}
However, this is not working with android configurations (configurations provided by the very plugin that was insisting for me to stop resolving at configuration time.) I get errors such as these: So the How can I correctly add a resolvable android configuration such as |
|
Aparently It seems I am caught in the middle. I can't resolve the configuration at configuration time or I will get an un-supressable warning from AGP. However, I also can't add it as a task input to resolve during task execution because it is not configuration cache compatible. |
|
To put my question simply: Is there any possible way at all to call
|
|
@mgroth0 In Gradle 7.5 the ability to use dependency resolution results as task inputs was added, which is compatible with the config cache. |
|
Not sure if the warning message is meant for final users (app developers) or for developers of various Gradle plugins (ie Google employees working on Android Studio)
Just in case, a valuable and useful case for this feature is documented here: Please don't remove the feature documented above ( |
BUILD SUCCESSFUL in 2m 9s Build Analyzer results available |
|
I'm still unsure why this ticket is still open, but I do get a bunch of notifications so here I am. IMO, this ticket doesn't really make much sense, especially with "modern Gradle". The idea, AFAIK, is to be able at some point to interweave configuration and execution, so that tasks which are configured and ready to execute can start while dependents are still configuring. Even if Gradle is not there yet, the configuration cache already provides improvements going in that direction. I don't think that forbidding dependency resolution at configuration time is, in that context, a good idea. It will certainly break some builds, while not being strictly necessary. I do agree however that for many builds this can be an issue, but that's an inspection which is already available for example in build scans. |
and others
After seeing even sophisticated Gradle users stumble over this countless times, I'm convinced that dependency resolution at configuration time should be an error by default. I'm hard pressed to think of any use case for it, but if there is we could allow it with a special method like
As a first step we could deprecate resolution at configuration time, pointing users at the user guide and performance guide for an explanation what configuration time is and why resolving dependencies during that phase is wrong. We could encourage them to get in touch in the forum if they think they have a use case that warrants it.
In the next major version we could then turn this into an error. Finally, if there are any good use cases for resolving at configuration time, we could create better APIs to solve those use cases. Then we could even remove the workaround method.
The text was updated successfully, but these errors were encountered: