This message was deleted.

it would be questionable to add to a collection after it’s been provided to a consumer.

It’s regular practice. Example:

task.dependsOn(tasks.withType<Jar>())

.

tasks.withType<T>()

isn't a plain collection, it's a

TaskCollection

which is a view into

TaskContainer

Anyway it should be stable by the time gradle calculates task graph, so changes after

TaskExecutionGraph#whenReady

callback is called would either lead to error or just ignored. Obviously some configuration could be done in that callback and

afterEvaluate

later when task graph is already frozen.

@grossws I’m interpretting what you are saying as confirming my expectation that Gradle calculates task dependencies only after all Projects are all evaluated. So, as long as

mySet

is not modified after

TaskExecutionGraph#whenReady

, then I’m fine?

No. I'm not familiar with gradle internals that much but since

whenReady

is still part of the project evaluation and task graph should be frozen by the time it's callback is called and evaluation continue afterwards. So projects are partially evaluated, task graph is built, evaluation continue. Just like with dependency graph, there are points in evaluation process where you still can change dependencies, and there are points in time when it's too late. IIRC Gradle throws an error if you try that with dependencies and has a callback to delineate these phases for deps. Not sure if

TaskExecutionGraph#whenReady

is such barrier and if error is thrown in case you try to modify task dependencies too late or if it's just silently ignored. What I'm saying is that it's totally not ok to modify such a collection after task graph is built. It doesn't mean that it wouldn't be frozen earlier.

What I’m actually using is

val mySet = project.objects.domainObjectSet(TaskProvider::class.java);