is there any way to watch for tasks created later (as in tasks.matching) but keeping lazy configuration? everything I checked suggests there isn't, but I wonder if there's any kind of obscure alternative...

tasks.matching

is fine, as long as you do

configureEach

on the result

oh, somehow I missed this 🤦‍♂️, thanks!

Yes, it would prevent you from registering other tasks in there. No, it does not realize all tasks itself. I thought so myself in the past but did thorough testing. Only if you use the result in another way like as argument for

dependsOn

or using

all

on it or

forEach

. As long as you only call

configureEach

on it as I said, it is properly avoiding task creation

how's that even possible, if

matching

needs to pass

Task

to a closure to do filtering, and before configuring it, rather than a

TaskProvider

, by the time you get the

Task

object, doesn't that mean that the task was created?

Well, docs are not always correct. But in most cases it indeed is somewhat correct. But calling

matching

itself does never cause anything to be realized or matched. But almost and usage of the resulting task collection will, like iterating over the task collection, depending on it, and so on. The only exception that is safe (that I'm aware right now) is calling

configureEach

on the result. In that specific case only configuration on anyway due to some other reason realized tasks is done, so only the anyway realized tasks are sent through the

matching

too. So yes, realized tasks are given to

matching

, but as long as combined with

configureEach

, only the anyway realized tasks are. If you don't trust my through testing or words, just try it for yourself with some `println`s, it just discard the option you have and don't use it though you could. ;-)

sure, I'll test it, it's not a matter of trust, it's just that it seems to contradict what I understood and tested so far, so I must be missing something

If anything else breaks task configuration avoidance, then all tasks are sent through

matching

, but that does not mean it caused it, just a red herring :-)

indeed, that was very likely the case

I tested it very thoroughly when trying to find the documented difference between

matching

and the newer

named { ... }

to finally find that erroneously there is no difference even though it should and thereby also learned about this detail. :-)

tbh this method makes an extreme difference on migration to lazy conf

Oh, btw.: https://github.com/gradle/gradle/issues/26047 🙂