Gradle puzzler for you all. Consider the following...
# configuration-cache
Gradle puzzler for you all. Consider the following:
Copy code
abstract class PrintMessageTask : DefaultTask() {

  abstract val inputMessage: Property<String>

  abstract val outputFile: RegularFileProperty

  fun run() {
    val message = inputMessage.get()

project.tasks.register<PrintMessageTask>("printMessage") {
Do you think that task will always be up to date, or never up to date? Do you think the answer changes if you're using the configuration cache?
Cheating: obviously you wouldn't be asking if it didn't change when CC is enabled
Random should mean it's "never" up-to-date, but CC .. makes it to be up-to-date always?
that's my experience
So, maybe the CC doesn't understand Random is a "changing input"
Maybe it's worth opening an issue about it
Yeah, memoization like Haskell at it's best
I don’t think this is a bug. It’s expected with the CC. You somehow need to tell Gradle that a value is computed if you grab it from somewhere “outside” of Gradle’s domain/scope. And
is a ‘computation’ Gradle does not know anything about. I assume this fixes it?
Jendrik, if not a bug, at least a very unintuitive side effect, and very likely to produce a lot of bug on third party plugins.
Definitely! Just wanted to point this out from a CC implementation perspective. I know it’s very difficult to deal with from the usability perspective. In particular for existing builds and plugins which did not follow these new paradigms. One of the reasons why getting the CC to a stable feature already takes so long and will probably still take much longer. Gradle should probably give an error if it can. But I am not sure if all these things can be detected (in a cheap way).
and will probably still take much longer
not that we can't use it, but.. 😢
As Jendrik wrote, this is expected. For changing values you should implement a
The code will be captured by CC and the value obtained on each build invocation including when loading the configuration cache.
I agree, but I brought it up because my initial reaction was "wow! that's not intuitive at all." And then I became afraid for the world of community plugin authors if anything, this really shows the value of testing one's plugins. but a plugin author has no control over the context in which their plugin is applied. and creating test fixtures should be easier