This message was deleted.

I don't see why that has anything to do with Kotlin accessors. https://docs.gradle.org/nightly/javadoc/org/gradle/api/NamedDomainObjectCollection.html#named-org.gradle.api.specs.Spec- is a more lazy-configuration-friendly version of https://docs.gradle.org/nightly/javadoc/org/gradle/api/NamedDomainObjectCollection.html#matching-org.gradle.api.specs.Spec-

If I remember correctly, calling named was being affected by the order of task registration, which looks like this new named is fixing.

no, it's to replace

tasks.matching { predicate(it.name) }

with

tasks.named { predicate(it) }

That implementation is not fixing this?

tasks.named("foo")
tasks.register("foo")

Task with name 'foo' not found in root project 'gradle-extensions-project'.

What would be the behavior of

// find `foo`? or this would be an empty list?
tasks.named { it == "foo" }.configureEach { ... } 
tasks.register("foo")

1. no, that's intentional and not to be fixed. if you use

named(String)

you expect a task to be registered already. 2. it's a live collection so the closure will be executed after the registration, same as

matching

1. That is really annoying, that task can be registered by another plugin or other configuration, creating a mental problem which is: "I need a

maybeCreate

which works lazily so I don't need to worry about".

maybeCreate

is also (almost always) the wrong solution too

Because it is not lazy, if not, which would the problem be?

just react to the plugin

That is the main problem, which plugin? You can't react to all plugins.

if more than one plugin is registering the same task then you have an issue, full stop

What could I do if the plugin is not doing the right things?

you can react to plugins applied to the root project, or you could fix their plugin by (if they insist on poking into subprojects) applying a sub-plugin instead of doing that directly

is not calling

withType<Task>

with

Task

a bad practice?

no,

withType()

is fine.

withType {}

is not.

I am not going to call

configureEach

in this case. I am creating another task which will depends on this task

if you want to react to task registration, you have to break configuration avoidance one way or another

I have no other way, registering those tasks with

allprojects

implies breaking calling

named

on subprojects without using

afterEvaluate

or

matching

. I would keep one of them as a workaround until the PR is merged