Question regarding 8.6 release notes: tasks.named

Help/Discuss
1

In 8.6

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

tasks.matching { it.name.contains("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:

// https://docs.gradle.org/current/release-notes.html

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 ->
    return s.name.startsWith("t")
}.configureEach {
    println "Configure in 'matching' ${it}"
}

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

Thanks
Boaz

1 Like
2

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

3

Thanks, appreciate it.