From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

You should have written this task like this instead:
```tasks.register("myTask") {
    val inputConfiguration: FileCollection = configurations.runtimeClasspath.get()
    inputs.files(inputConfiguration)
    val outputFile = layout.buildDirectory.file("output.txt")
    outputs.file(outputFile)
    doFirst {
        outputFile.get().asFile.writeText(inputConfiguration.files.joinToString { "${it.name}: ${it.readBytes().size}"})
    }
}```
Execution time depends on configuration (and configuration cache respectively), not vice versa

&gt; Execution time depends on configuration
I mean that's a constraint introduced by CC, right?

Without CC the code above works well. I'm guessing because evaluation of the provider is postponed to `:app:myTask` execution (or just before I guess, not sure), which seems to be enough to let `:lib:jar` the time to execute.

CC seems to capture that constraint at the "graph" level

Whereas without CC it's more of a "task" level thing

&gt; I mean that’s a constraint introduced by CC, right?
I guess it is a general direction where Gradle goes — defining more strict rules to be able to optimize things and keep them understandable. This particular thing may be a bug, but I’m not sure, may be someone from Gradle team could answer more precisely.

Documentation of `TaskInputs.property` says:
&gt; If the value is not known when registering the input, a org.gradle.api.provider.Provider can be passed instead. Gradle will then resolve the provider at the latest possible time in order to determine the actual property value.

but if the value of your provider was resolved at execution time, it would fail because it calls `configurations` on the `project` instance, which usage is restricted with configuration cache at execution time.