This message was deleted.

For instance, is there an internal Gradle API I can call that will attempt to perform this serialization? Something I can step through in a debugger?

all the fields are there - it’s very messy, there’s a bunch of stuff stored that shouldn’t be. You shouldn’t be caching a Task instance.

I find this hard to understand: we're supposed to use tasks as inputs to other tasks, right? So why don't Task instances normally get cached?

It isn’t the task itself that is the input to other tasks, its (output) properties of one task that are passed into another. CC serializes the configuration of projects/tasks. You’ll need to use the object graph to understand which attribute(s) are problematic and track down where they are being set.

In other words, the

Task

instances aren't serialized, but their modeled inputs and outputs are?

No, it's exactly the task instances that are serialized and of course along with that their inputs and outputs as they are fields of the task instance. But not all types are allowed and tasks are not.

Let me rephrase to see whether I'm following this explanation. 1. CC's job is to serialize task instances. 2. However, CC does not permit tasks to refer to each other directly. In other words, when serializing any given task, if another task is encountered in the object graph (as a field, or a field of a field), it is a CC error. 3. The ability of one task to accept another as input, as in

files.from(codeGeneratorTask)

, is an illusion created by Gradle's API. Internally, what's really happening is that the consuming task gets a reference to the producing task's output properties (e.g. file system locations), as well as some sort of task dependency metadata, but nowhere in the consuming task's object graph is there a reference to the producing task itself, and hence it is not serialized.

Pretty close. CC serializes more than just task instances - various project attributes, such as properties; contents of gradle.properties; and a few other tidbits necessary for a holistic view of configuration that can be restored.

Yeah, "given THIS exact state of the world, you want THIS task graph"

yep

I have a very specific problem I'm trying to solve that looks like this: 1. I have a

FileTree

, produced by a task, which produces a bunch of files that I need to filter. 2. I first want to apply one set of filtering criteria. 3. If and only if that first set of criteria results in an empty file collection, I want to fall back on a second, broader set of filtering criteria. I've been pursuing a particular strategy of creating a provider that calls

getFiles()

on the

FileTree

in step one and proceeds from there. It showed promise, but then I discovered this CC issue. So now I'm concerned that I've outsmarted myself once again by introducing cross-wiring between tasks

FileTrees are inherently lazy and don’t need a provider; you should be able to create one with the correct filtering criteria and pass that to a task. And perhaps create a second one, so the task can decide (at execution time) which one to use (the second one if the first one is empty)

Agreed, that would in fact be more straightforward. There are some side effects (modeling inputs to files I never look at) but they have no practical impact for my use case