Question regarding 8.6 release notes: tasks.named

In 8.6

Previously, filtering tasks by name required using the matching method using the following pattern:

tasks.matching {"pack") }.configureEach {
    // configure details of all '*pack*' tasks that are part of the task graph

The problem was that calling matching triggered the creation of all tasks, even when the task was not part of the build execution.

End of quote

I don’t understand this paragraph. tasks.matching { }.configureEach { } doesn’t trigger creation of all tasks.
The sample code demonstrate it:


class TX extends DefaultTask {
    TX() {
        println "Task ${this} was created"
tasks.register("t1", TX) {
    println "${it} is configured"

tasks.register("t2", TX){
    println "${it} is configured"

tasks.register("t3", TX){
    println "${it} is configured"

// causes all to be realized, because you configured the instance
tasks.matching { Task s ->
}.configureEach {
    println "Configure in 'matching' ${it}"

When executing “t1” , then it is the only one that is created/configured.
What do I miss ?


1 Like

Actually, I just happened to wonder about the same.
matching combined with configureEach always acted avoiding and still is doing so.
From my experiments currently matching { ... } and named { ... } behave identical,
while I hoped tasks.named { ... } would also work like expected with .all, .forEach, dependsOn(...), and so on.

I just created this: Please clarify the sense of `tasks.named { ... }` opposed to `tasks.matching { ... }`, also in release notes, resp. actually make them behave different · Issue #28347 · gradle/gradle · GitHub

Thanks, appreciate it.