https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
v
Are you talking about task collections or other collections?
k
Not task collections specifically. Just generic named domain object collections, on the basis of "names are eager". Though task collections is probably one of the few places where there is a lot of emphasis on the distinction between creating and registering.
v
What is the problem with using 
matching
then?
k
The documentation on 
matching()
states that it would force object creation, defeating the purpose of registering, where there would exist a distinction between creating and registering. If there isn't a distinction, then yes, 
maching()
would suffice.
v
The documentation is not fully correct, it depends on what you do with the result of 
matching()
If you for example do 
tasks.matching { it.whateverNotJustName == bla }.configureEach { ... }
it is ok. Even using the actual task properties does not disturb task configuration avoidance. The condition will only be checked for the tasks created anyways.
If you do 
dependsOn(tasks.matching { it.name == "foo" })
or any other action that iterates of the result of 
matching
then it would be bad, as that would cause each and every task to be realized to check the condition
k
Duly noted. That should probably be made more clear so that I wouldn't write off 
matching()
as being completely useless.
Still, for the case where I have to work around 
dependsOn(tasks.matching())
, what would be a suitable alternative? Trying to extricate the names from a filtered 
TaskCollection
and obtaining "fresh" providers from the unfiltered one?
v
There is no good way I'm aware of. Only limiting the realized tasks by type so that at least only the tasks of that type are realized due to the name-matching. Or just 
dependsOn("myTask")
of course if you know the full name.
Open in Slack
PreviousNext
Powered by