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

Gradle Community

I tried raising an exception, but stracktrace is not very helpful. At least I couldn’t find which task requested the creation..

Maybe build scans? <https://scans.gradle.com/>

Sorry, forgot to mention that. I meant in the build scan how can I determine tasks that were created during configuration.

I see a number (as described in the guide above) however I cannot a list of the tasks created.

added a comment in the MavenPublish CC issue:
<https://github.com/gradle/gradle/issues/13468#issuecomment-1190108302>

We moved all our build scan environment/file capture to `buildFinished` to avoid false positives. They were in `background` but that can currently race configuration. This plugin would have to do the same

are they not tracked for configuration cache if we use them in buildFinished?

No, because they're not accessed at configuration time. Anything that happens at execution time is fair game

great! Thanks

I didn't know how buildFinished works internally (and GE plugin obfuscation makes things complicated).

I'll try and maybe open a PR

These checks ensure that implicit inputs to configuration are known and can invalidate the cache. Avoiding versioning your PR and other non-release builds would help with your first case. Publishing isn't currently configuration cache ready anyway

(I think last answer was for the previous message, I split them consciously to not mix issues)

I publishing was mine I would try to read version and other pom properties in execution of GenerateMavenPom task

those properties are to generate a file (at one task), no need to read them in configuration time

Based on what I've seen so far, that wouldn't help. The version is used in properties configure tasks, so it's an input to the configuration/task graph. Configuration caching in this case is going to have the benefit of providing the guarantees for per-project parallelism, but not provide cache reuse on CI (unless it becomes more granular I guess? Someone on the Gradle team may be able to clarify)

I said MavenPublication.version, not project.version, and I think that's key

I don't expect MavenPublication.version to be read in configuration time to configure anything else

Artifacts have the version in filenames, manifests/metadata has versions, etc. All task properties set at configuration time

:thinking_face: I'll trust you, but all what you said are task ouputs (used as iinputs by other tasks) so they should be read only in execution time.

May be that the lazy APIs change things, I haven't looked deeply into how much is resolved/serialised

You should also include `project.task` which is the very old API for creating tasks.

You could also include `tasks.matching` to prefer (unofficially) `configureEach { if (it.name == '…') { .. } }`

The `tasks.findByName` can’t be easily replaced by `tasks.named`. The returned provider is always present and the method will throw an exception if the task doesn’t exists. The lazy equivalent is to use the collection schema which is quite verbose.

&gt;  The lazy equivalent is to use the collection schema
Does this refer to `tasks.names.contains("...")` ? That’s what I sometimes used to avoid `findByName` .

I wish gradle would offer a way to enforce this api in an easy way

&gt; Does this refer to `tasks.names.contains("...")` ?
Good questions, looking at the code shows that `schemaCollection` uses `getNames()` in all named collection except the `TaskContainer` which uses the index… pretty messy. Either way, there isn’t a good way to `findByName` lazily as rules are not applied via `names` or `schemaCollection`.

This has come up several times, but other than probing for the existence of a task by name, is there any other reason to need to do this?

IMO, `tasks.names.contains(...)` or `tasks.findByName(...)` are nearly as bad as `tasks.each {}`.

What we usually need is `registerIfAbsent`. My thinking around that have been mostly a method that takes the name (and type for polymorphic container) and return the existing configurable provider. It would need to assert for existing the type specified also match.

Some users uses the existence of a task to check if a plugin or some logic ran. For this use case, I would generally say it's wrong. They should react to the plugin that provide the logic. This becomes a bit tricky when several plugins can provide the same logic.

`base` plugin vs `lifecycle-base` plugin is a great example.

Suppose you want to attach something to the assemble task if it exists. You need to check for both plugins.

it does, but I think what's you're saying is that two plugins create the same named task and you want to work with either of them

so two calls to `withPlugin(...)` would cover that?

If you don't do that, then you're at the mercy of users to apply the plugins in the correct order

Well it's more complicated, the two calls needs to ensure the action for both is only executed once. With plugin type, we can check for a super type but with plugin id, you need some sort of OnceAction implementation.

I'm not sure about that... it should only be called once either way

you're not saying it's called more than once for each plugin

Because the logic will now have two entry point.

So you're trying to protect against plugin1 and plugin2 being applied together?

Yes, which some cases, despite providing the same capabilities, they could be compatible on together. The joy of plugin development. :smile:

Right, but for the use case we're talking about (plugin1 creates a task foo and plugin2 also creates a task foo), it doesn't matter if both of them are applied and your plugin reacts to both.  plugin1 or plugin2 would fail to apply first

Unless plugin1 or plugin2 has its own implementation of registerIfAbsent which would not fail. Regardless, the case I was mentioning is using the existence of elements (i.e. Tasks) as a way to check if a plugin is applied (indirectly). This case, would be wrong in my opinion.

We can continue the conversation somewhere else to avoid hijacking this thread.

Right, but in plugins that don't have registerIfAbsent or use findByName, this isn't a problem. In the same way we would fix other things, we should fix those plugins.

I have to go get dinner soon, so I won't be able to argue any longer :slightly_smiling_face:

Re <https://gradle-community.slack.com/archives/CDB9Q0MPT/p1657922760596069?thread_ts=1657723045.432819&amp;cid=CDB9Q0MPT|https://gradle-community.slack.com/archives/CDB9Q0MPT/p1657922760596069?thread_ts=1657723045.432819&amp;cid=CDB9Q0MPT>

I usually use this if I can't work around it in a different way: <https://gradle-community.slack.com/archives/CDB9Q0MPT/p1657922760596069?thread_ts=1657723045.432819&amp;cid=CDB9Q0MPThttps://github.com/TWiStErRob/net.twisterrob.sun/blob/master/gradle/plugins/src/main/kotlin/net/twisterrob/sun/plugins/internal/maybeRegister.kt|https://github.com/TWiStErRob/net.twisterrob.sun/blob/master/gradle/plugins/src/main/kotlin/net/twisterrob/sun/plugins/internal/maybeRegister.kt>

Btw, <@UN84RHR40> thanks for these issues. I was just wondering about these last night, because I forgot the difference between `withType&lt;T&gt; {}` and `withType&lt;T&gt;().configureEach {}`

Is there a question hidden, or is it just a sad statement? Besides that you probably wanted <#C013WEPGQF9|>

Then please post it to the appropriate thread and delete this one. :-)

Or like an additional case where it surfaced

There are two threads so I decided to not thread to not make the communication more complicated

Confusion is majorly anyway already at it is the totally wrong channel :-D

Yes I wrote in the wrong channel by mistake.

And <@URA60C7T9> if you find a workaround please share it

You probably need <https://github.com/gradle/gradle/issues/20873|https://github.com/gradle/gradle/issues/20873> for that

Not really, the issue in my case is that version is not lazy for a maven publication, not entirely sure about Paul's issue.

Tough task I'd say.

There is no way to do `matching` without realizing the tasks as long as you want to check a property of the task because for checking a property of the task, the task has to be realized.
So matching will always realize all tasks on which it is called, so in your case all tasks of type `Task1` and of type `Task2`. That's also the reason why `tasks.matching { ... }` is a bad idea as it will realize each and every task.

The only alternative is to check the variant at configuration time, something like `tasks.withType&lt;Foo&gt;().configureEach { if (variantName == variant) { ... } }`, but this pattern might not apply here in your case.

The `?:` on `Provider&lt;Task&gt;` would be `task1.orElse(task2)` if you would actually have `Provider&lt;Task&gt;` instances.

That actually sounds feasible, `configureEach` might work, the problem is how do I pick both of them.

I'll have a deeper look, but this might be enough + some serious refactor on the way it works, so that I can remove the need to know about both tasks at the same time, which means that configureEach will be a nice and clean way.

Also I would like to acknowledge the "Tough *task* I'd say." :drum_with_drumsticks::large_yellow_circle:.

Looks like it's success. Rather than doing the `?:` fallback I just did `configureEach` for both tasks with a variant-filter inside the configureEach. It was a bit complicated to split the setup of `someOtherTask`, but that's the price for lazyness :smile: Thanks for the idea.

My first idea is to do `project.tasks.configureEach { created.add(it) }` and then invoke `gradlew :help`.

<https://github.com/TWiStErRob/net.twisterrob.gradle/pull/253/commits/bd380f95ee676046f45d70dae5a47508bcf55845>

Still open to better solutions.

When testing you could inject some code that increments a global counter from within the init block and then verify that counter.

throw an exception in task configuration action and run `help` task. Build should complete successfully if configuration avoidance is working

<@URA60C7T9> as far as I understand your suggestion my "global counter" is the list of tasks created, so that's the same as my proposal, unless I misunderstood "init block".

<@UACGKT8S1> that's a good idea, I used it as well, but not from configureEach, because that would eagerly fail the build on the first task creation. When waiting for the end, it might highlight a pattern if all the tasks are known which misbehave. So I throw instead when the task graph is calculated.

`--dry-run` will skip task actions but it will still calculate the task graph, hence creating necessary task instances

:thinking_face: So how should I figure out appropriate number of `created during configuration` tasks? I thought it should be `0`

That thread above might help <https://gradle-community.slack.com/archives/CDB9Q0MPT/p1661104674880079>

Ideally running `:help` should only create that task. That's one test case you could start with

I think that helps, I still get a number of tasks created with just `./gradlew help --no-configuration-cache --scan` :slightly_smiling_face:

There's info in the other thread I linked that would help you get a list of the created tasks. From there you can investigate

You can also use `--dry-run` when testing for this because you don't care about running the task actions.

<@UN48QB093> note that you don't need to automate this, but it's best if "Created during configuration" is 1 with `gradlew :help`. Because that number shows how many tasks were created when they were definitely not going to be executed, which wastes everyone's time during Gradle Sync, and even when executing any task, as the majority of those tasks might be unused.

In my experience most of the time it's a simple `configureEach` missing, see commits listed in the table here: <https://github.com/TWiStErRob/net.twisterrob.sun/pull/121>

Iirc if you really need all and not just the ones that are going to be executed, there is currently no lazy way.

I’m inclined it is worth having `container.allNames {...}`  which executes for all the registered item names even in the case they won’t be realized.

Here’s the relevant discussion: <https://github.com/gradle/gradle/issues/8057#issuecomment-456956567>

```public inline fun &lt;reified T : Task&gt; TaskContainer.namedLazily(
    name: String,
    action: Action&lt;in T&gt;? = null,
): TaskCollection&lt;T&gt; {
    val collection: TaskCollection&lt;T&gt; = withType&lt;T&gt;().matching { it.name == name }
    if (action != null) collection.configureEach(action)
    return collection
}```

```public inline fun &lt;reified T : Task&gt; TaskContainer.maybeRegisterLazily(
    name: String,
    action: Action&lt;in T&gt;? = null,
): TaskCollection&lt;T&gt; =
    if (names.contains(name)) {
        namedLazily(name = name, action = action)
    } else {
        register&lt;T&gt;(name)
        namedLazily(name = name, action = action)
    }```

Creating a custom maybeNamed should be similar to those ones 

<@URQ797WRW> part of the issue context: I'm adding all the reports from Test tasks to a configuration to expose it to another project (and configuring the tasks lazily later)

I guess there should be something similar in gradle test-report-aggregation

<@U01DUV4Q882> how is your `namedLazily` lazy?
`matching` realizes all tasks the predicate is matched against, so it is not lazy at all. Same for your `maybeRegisterLazily` then of course.

<https://melix.github.io/blog/2022/05/gradle-laziness.html|https://melix.github.io/blog/2022/05/gradle-laziness.html>

&gt; Well, not so fast. You’ve used configureEach, so everything should be lazy, right? Sorry, nope: the matching API is an old, eager API! Actually, if you look at what the predicate uses, it becomes obvious:
&gt; 
&gt; // T is a Task!
&gt; TaskCollection&lt;T&gt; matching(Spec&lt;? super T&gt; var1)
&gt; Because it works on Task instances, it needs to create and configure the tasks so that you can run an arbitrary predicate on them!
&gt; 
&gt; That’s why if you have to write things like this, you must guard calls to matching with a withType before, which will restrict the set of tasks which will be configured. For example:
&gt; 
&gt; tasks.withType(Greeter).matching { it.name == 'hello' }.configureEach {
&gt;    messages.add("World!")
&gt; }
&gt; 
&gt; tasks.register("hello", Greeter) {
&gt;    messages.add("Hello,")
&gt; }

So? The blog just says the same as I do.
Your version is *not* lazy, but will realize all tasks of that type.

<@U01DUV4Q882> so, not lazy:
&gt; which will restrict the set of tasks which will be configured

&gt; I'm adding all the reports from Test tasks to a configuration to expose it to another project
I guess you should simply not use `tasks.withType` then?
Maybe just support JVM test suites and react to them?

hum...I was looking at test-report-aggregation now..but not the change I want to do in a open source plugin it's not entirely mine, also it also configures other types of tasks that are not tests (in this case JavaExec tasks)

Well, if it configures the tasks, `withType` and then a `configureEach` is perfectly fine.
But wanting the names of all tasks of a type without getting the tasks realized is simply not possible with the current API afair.

that's why I was saying.. maybe adding a live collection of `names`  or `registeredTaskProviders` would be great

Looking through code for `org.gradle.api.internal.tasks.DefaultTaskContainer#findByName` it appears to realize tasks.

The one requested task of course, return value is `Task`.
But not all of that same project that are unrelated?

hard to tell from the code - looks like perhaps it’s realizing everything in that path, e.g. everything under `:foo` 

Hm, no, it does not, I just tried in a play project.
Must be something else.

good news there.  Perhaps set a breakpoint in `org.gradle.api.internal.tasks.DefaultTaskContainer#realizeTask` to see what trips into there.

Yeah, I'm at debugging step already.
Those details are just a hell to debug. :smile:

yea, feel your pain there.  Just did a whole debug cycle on a CC serialization issue, omg… (turns out the error was emitted as a debug message).

Argh, it is the properties plugin using `tasks.all` :face_palm:
<https://github.com/stevesaliman/gradle-properties-plugin/blob/993e1056ddb208e80a53d6b5fd724f2e36d00e28/src/main/groovy/net/saliman/gradle/plugin/properties/PropertiesPlugin.groovy#L432|https://github.com/stevesaliman/gradle-properties-plugin/blob/993e1056ddb208e80a53[…]vy/net/saliman/gradle/plugin/properties/PropertiesPlugin.groovy>

What do you think of “Gradle Strict Mode” plugin that would fail `tasks.all` and similar methods?

You are probably after `providers.gradleProperty` I guess

But you should consider using proper `@Option`s instead.
Except probably if you need to be able to set it via properties file.

Thanks, `providers` is what I missed, I was looking for top-level stuff :slightly_smiling_face:

So I got
```val ignoreFailuresProp = providers.gradleProperty("ktlint.ignoreFormatFailures").map { it.toBoolean() }.orElse(
true)
tasks.withType&lt;FormatTask&gt;().configureEach {
    ignoreFailures.set(ignoreFailuresProp)
}```
and I’m wondering if it’s in any way more appropriate or better than reading the property right away. I guess now it’s read lazily, what if there’s more than one `FormatTask` in the project — will it be read more than once? I tried to follow implemention and docs but can’t tell for sure

And I realize reading Gradle property might be pretty cheap, I’m wondering as a general rule if properties cache their values

&gt;  But you should consider using proper `@Option`s instead.
That would be on the task author, right? In my case it’s a 3rd party plugin

&gt; Except probably if you need to be able to set it via properties file.
actually I do :smile: That’s a preference team members would set for themselves, having to pass it when running Gradle wouldn’t be ideal

Ah, ok, then yeah. And yes, would be the task author.

A property is calculated each time it is requested afair.
And a `map` for similar step the same.
But you can easily create a cached provider like
```inline fun &lt;reified T&gt; cachedProvider(crossinline block: () -&gt; T): Provider&lt;T&gt; =
    objects
        .property&lt;T&gt;()
        .value(provider { block() })
        .apply {
            disallowChanges()
            finalizeValueOnRead()
        }```
And then you can use it like `val foo =  cachedProvider { calculateComplexValue() }`

Is the caching part achieved by setting `value(provider { block() })` or by `disallowChanges(); finalizeValueOnRead();`? :thinking_face:

ah, the disallow/finalize are methods on a `property`, not `provider`  :+1: Looks like it’s not really worth it for a gradle property per se, but good to know how to achieve laziness in similar cases :slightly_smiling_face:

`disallowChanges` effectively makes the `Property` a `Provider` or someone could downcast and call mutators.
`finalizeValueOnRead` makes it calculate once and remember.

The `provider { block() }` makes the value be calculated only on first read

Alternatively the function could require a `Provider` as input, but I liked it better that way, usage-wise

Got it, thanks a lot :slightly_smiling_face:

TIL about the prop. It seems that `LifecycleBasePlugin` calls `buildOutputCleanupRegistry.registerOutputs`where a FileCollection is recorded. This is lazy so far, but then someone calls `DefaultBuildOutputCleanupRegistry.resolveOutputs` which iterates through the `File`s in the collection. `DefaultBuildWorkPreparer#finalizeWorkGraph` calling `resolveOutputs` seems a bit random, curious to blame why this was added.

Lines were added <https://github.com/gradle/gradle/commit/e1f6ee48f13f311702fa9a39c8cc8523ff4286d7#diff-39077191beefbb96df4ee7dca97e6bef6f0e24d9615db4f6243aa8ea2bc48760R37-R38|here>, but it was moved from the file above. This commit was in 7.3, so running with Gradle 7.2 to confirm the behavior didn't change. On 7.2 the task is not realized, but on 7.3 it is.

Thanks for your investigation, I'll verify here that it changes from 7.2 to 7.3 and then report a regression

```plugins {
	id("lifecycle-base")
}
tasks.configureEach { println(it) }```
7.2 output:
```task ':help'```
7.3 output:
```task ':help'
task ':clean'```
feels like a regression report

oddly enough I have an integration test that verifies task creation and it's running on Gradle 7.0-7.6, yet it passes on all:
<https://github.com/TWiStErRob/net.twisterrob.gradle/blob/master/test/integration/src/test/kotlin/net/twisterrob/gradle/PluginIntegrationTest.kt#L306-L324|https://github.com/TWiStErRob/net.twisterrob.gradle/blob/master/test/integration/src/test/kotlin/net/twisterrob/gradle/PluginIntegrationTest.kt#[…]4>

<https://github.com/gradle/gradle/issues/24492>

btw, `org.gradle.internal.tasks.stats=stats.txt` is the correct format, it'll create a file with stack traces, although `./true` also works, just a bit funny

Oh, interesting, there is a file `true`, didn't notice. :smile:

that's how I knew what was creating the task, because of the stack traces

I just set it to `true` as I thought it is a boolean flag

I just did set a breakpoint on the field initialization of `Delete` to see where it comes from

It was just yesterday, but I forgot where :smile:

Actually, it also was mentioned in the docs in the past: <https://docs.gradle.org/5.0/userguide/task_configuration_avoidance.html#sec:how_do_i_know_its_working>

ah, I see now, that's why there's an .isEmpty() at the usage

Yep, if you set it to an empty value, you just get the summary in the build output

do you use this tool to find implementation details in dependencies?

I right away added `<http://systemProp.org|systemProp.org>.gradle.internal.tasks.stats` to my user-specific `gradle.properties` :slightly_smiling_face:

Right now I just used `tig grep` as I had the Gradle sources open in commandline anyway :smile:

Ah, here it was: <https://gradle-community.slack.com/archives/CAHSN3LDN/p1679555593798399?thread_ts=1679516495.204559&amp;cid=CAHSN3LDN>

And your test works, because the `clean` realization is after your test.
Your test code says
&gt; ```// Note: this will execute after whenReady in some cases, but it doesn't matter as no-one will read it.```
And that is what you are hitting here

but then the task is created in the execution phrase, no?

I added a `println` to the two closures of your test code and a breakpoint in the `Delete` initialization:
&gt; task ':help' was created before root project 'showcase' was configured.
&gt; Breakpoint reached at org.gradle.api.tasks.Delete.&lt;init&gt;(Delete.java:46)
&gt; {task ':help'=java.lang.Exception: task ':help' was created before root project 'showcase' was configured.}
&gt; task ':clean' was created before root project 'showcase' was configured.

Becuase the breakpoint comes before your `whenReady` but the `tasks.configureEach` comes after

I think we need to stop, the rabbit hole is almost in Australia now.

Setting breakpoint at all three places shows it actually is
&gt; task ':help' was created before root project 'showcase' was configured.
&gt; {task ':help'=java.lang.Exception: task ':help' was created before root project 'showcase' was configured.}
&gt; Breakpoint reached at org.gradle.api.tasks.Delete.&lt;init&gt;(Delete.java:46)
&gt; task ':clean' was created before root project 'showcase' was configured.

So yeah, `clean` could be considered as realized not in configuration phase.
But build scan and the stats state it was created in configuration phase.
And even if it is in execution phase it is questionable whehter it should always be realized. :slightly_smiling_face:

We'll see what the Gradle guys say about it.

Probably mention that in the issue, because it's an important symptom of this unexpected task creation.

or a separate issue :slightly_smiling_face:

But actually, the classification is correct.
If you build with configuration cache enabled, the `clean` task is not created.

But that unveiled another quirk.
Now that also the run that stores CC uses the same run-logic with parallel execution on the first invocation, tasks are created twice.
And they are reported as created with the old API / immediately.
So first run now shows `help` with old API / immeditaley, `help` lazily and `clean` during configuration.
Second run shows only `help` with old API / immediately.

So your test is too early to test after configuration phase :smile:

thanks for discovering <https://github.com/TWiStErRob/net.twisterrob.gradle/issues/437>

Maybe use that internal property and check the output as long as the property is available

<https://github.com/gradle/gradle/issues/24494>

And finally <https://github.com/gradle/gradle/issues/24495> :slightly_smiling_face:

also this means that I don't really run it on all versions:
```tasks.withType&lt;Test&gt;().configureEach {
	onlyIf {
		it.project.property("net.twisterrob.test.android.pluginVersion").toString() == "7.3.0" &amp;&amp;
		it.project.property("net.twisterrob.test.kotlin.pluginVersion").toString() == "1.6.21"
	}
}```

or maybe even 0, because 7.3.x must have patches

For context, I'm trying to configure my extension with a default value:
```// val directory: DirectoryProperty
directory.set(
	project.providers.gradleProperty("net.twisterrob.gradle.release.directory")
		.map { project.objects.directoryProperty().fileValue(File(it)).get() }
		.orElse(project.layout.buildDirectory.dir("release"))
)```

What if you `flatMap` instead of `map { ….get() }`?

I still need to do `objects.directoryProperty` and also I would lose the source.

In this case it's a not a biggie, but it could be a Task backed `Provider&lt;String&gt;` I'm mapping on.

Sorry, should've been more explicit, updated question.

Does `layout.projectDirectory.dir(..)` work for your use case?

It's likely an absolute path outside of the project.

Although the doc of `Directory.dir` says it could be absolute.

Still a weird one, but a nice way to allow relative paths too. I'll take `projectDirectory` as a "better way" because it improves the logic. Still a bit strange not having just `objects.dir`.

but then I need a provider :face_holding_back_tears: ... `project.layout.dir(project.provider { File(it) } }`

oh wait... I see what you mean:
```directory.set(
	project.layout.dir(project.providers.gradleProperty(RELEASE_PROPERTY).map { File(it) })
		.orElse(project.layout.buildDirectory.dir("release"))
)```

Exactly.

```directory.set(layout.dir(providers.gradleProperty("my.dir.prop").map { file(it) }))```

Thank you <@U042816HVD0> I think this is sufficiently clean:
```val defaultReleaseDir = project.layout.buildDirectory.dir("release")
val externalReleaseDir = project.providers.gradleProperty(RELEASE_PROPERTY).map(project::file)
directory.set(project.layout.dir(externalReleaseDir).orElse(defaultReleaseDir))```

Hmm.... <https://github.com/gradle/gradle/blame/master/subprojects/core/src/main/java/org/gradle/api/internal/tasks/DefaultTaskCollection.java#L69-L78>

could that be a doc issue?

Could be, but that would be a very bad and painful one. I tell people all the time not to use it if possible and instead use things like `tasks.configureEach { if (name == "...") { ... } }` instead which is arguably way less readable and also just works when configuring, but not when consuming.

I'm giving it a few work-days to see whether some core dev leaves a note here.
But most probably I will eventually report it, yeah, and if only to definitely clarify.

as soon as you access more than `name` in the `matching {}` lambda, then it configures tasks

accessing just the `name` is safe wrt. lazy configuration

I also tried with `enabled` and the tasks were also not configured

do you parse into the lambda to know what it accesses? the parameter type is Task, isn't it?

I would have not expected parsing but a dynamic proxy

But I might be mistaken wrt the config avoidance here :thinking_face:

```tasks.matching { it.enabled == true }.configureEach { println("configure enabled task $name") }
tasks.named("check") { println("configure check") }```
=&gt;
```configure enabled task help
configure enabled task clean```

```tasks.matching { it.enabled == true }.all { println("configure enabled task $name") }
tasks.named("check") { println("configure check") }```
=&gt;
```configure enabled task assemble
configure enabled task build
configure enabled task buildDependents
configure enabled task buildEnvironment
configure enabled task buildNeeded
configure enabled task check
configure enabled task classes
configure enabled task clean
configure enabled task compileGroovy
configure enabled task compileJava
configure enabled task compileTestGroovy
configure enabled task compileTestJava
configure enabled task components
configure enabled task dependencies
configure enabled task dependencyInsight
configure enabled task dependentComponents
configure enabled task groovydoc
configure enabled task help
configure enabled task init
configure enabled task jar
configure enabled task javaToolchains
configure enabled task javadoc
configure enabled task kotlinDslAccessorsReport
configure enabled task model
configure enabled task outgoingVariants
configure enabled task prepareKotlinBuildScriptModel
configure enabled task processResources
configure enabled task processTestResources
configure enabled task projects
configure enabled task properties
configure enabled task resolvableConfigurations
configure enabled task tasks
configure enabled task test
configure enabled task testClasses
configure enabled task wrapper
configure check```

Right. It looks like `matching {}` is safe but it puzzles me because you need the task instance in the lambda...

You last example is nice. I would even remove `tasks.named("check") { println("configure check") }` from it as it only adds noise (this is what tripped me into the wrong of my first comment here)

I think that line proves that the task was not created.

my thinking is that replacing .configureEach by .all after a .matching shows already the difference

The example evolved. :smile:
And it still proves with `configureEach` that the task is not realized :slightly_smiling_face:

In any event, please open an issue with a reproducer. There might be details lurking in there but the documentation should be clarified

Who wrote to the docs, that `matching` is evil? Maybe that person has further insights.

&gt; with a reproducer
do you think more is necessary than shown?

Even without anyhting else in the build it reproduces, just with a few less tasks

Yeah, either something we can clone or a snippet that is the full build script.

As I said, that single line *is* the full build script :smile:

image.png

<@UAFD2T2QG> changed with commit fab3f321ce001220e4172db4181ef53ac97cd7f3 for 7.3 the docs with comment "Clarify impact on task avoidance when using tasks.matching(Spec)".

Actually, I thought it was always said to not use it.

I'm really confused where that info came from then.

Various sources cite this.  For <https://discuss.gradle.org/t/lazy-task-will-be-configured-even-if-it-should-not/40609|example>.
&gt; `project.tasks.matching` calls `TaskContainer.matching(Closure)` which passes every task to the predicate. This requires each task to be instantiated and configured.

This <https://melix.github.io/blog/2022/05/gradle-laziness.html|one>.

It seems this silently changed (improved) at some point actually.

&gt; _tasks_.matching *{ it*.name == "check" *}*.configureEach *{* _println_("configure enabled task $_name_") *}*
*with 5.0 =&gt;*
```configure enabled task buildEnvironment
configure enabled task components
configure enabled task dependencies
configure enabled task dependencyInsight
configure enabled task dependentComponents
configure enabled task help
configure enabled task init
configure enabled task model
configure enabled task projects
configure enabled task properties
configure enabled task tasks
configure enabled task wrapper```

Current docs are contradictory - perhaps the improvements started to roll into there, but not all the way…

Oh, no, forget that. I changed the Kotlin file to `configureEach` but still had `all` in the Groovy DSL file which then was used that I added to try whether the DSL makes a difference

Ok, it seems to be more edgy.
If you query the task collection, like with
```tasks.register("foo") {
    dependsOn(tasks.matching { it.enabled == false })
}```
which effectively does not depend on any task, still all tasks get realized to check the predicate.

But using `tasks.matching *{* ... *}*.configureEach { ... }` works perfeclty fine lazily. o_O

Are you calling `gradlew :foo`? Because task graph calculation needs the dependencies, so that might resolve it, right?

Whether I execute `:foo` or `foo` doesn't make a difference

I mean, the task is executed, therefore Gradle needs to know if there are dependencies, so it needs to realize the TaskCollection to see what's inside.

Yes.
That's what I practically said.
Neither the docs up to 7.2 nor the docs from 7.3 on are correct.
For certain use-cases like calling `configureEach`, it is perfectly fine lazy.
For other use-cases like usage in `dependsOn`, it breaks task configuration avoidance.

is `dependsOn` really a breakage of configuration avoidance?  If task X is being executed then its dependencies needs to be realized.

Is the `dependsOn` use case forcing realization of all tasks or just the matched ones?