How to find TaskProvider by name without failing if not exists

How can I check if a task already was registered without creating it eagerly?
I only found tasks.findByName which creates the Task if found.
The method to get the TaskProvider (named) will fail, if the Task does not exist.

What is the use-case, what do you want to do with that information or provider?
Depending on your answer, the right solution is different.

I have several conditions, under which a certain task should be created, and if one condition was met and the task is already there, I need to check if it already exists when the other condition is evaluated.

Guess I could use NamedDomainObjectCollection.getNames and check if it is contained there, but what I need would be some maybeRegister similar to maybeCreate.

Oh, and I have another use case, where I want to configure a Task only if it is already registered. Do nothing otherwise.

I’m still not sure whether your general tactic is a good one. :smiley:

But for both, checking getNames() whether it contains the task name is indeed the way to go, the “maybeRegister” as well as the “configure if already registered”.

Except if the latter one really meant “configure if it is already registered or is registered in the future”, then it would be tasks.named { it == "..." }.configureEach { ... }.

Thanks for your answer!
Do you now a reason, why there is no simple find-without-fail or maybeRegister function for those containers? Using getNames feels a bit awkward.

To give you more info about my use case:
I automatically generate tasks for files that exist in certain paths, so my developers only need to drop their code in the right place and it’s getting handled as necessary.
Therefore, I need to configure or extend the configuration of those tasks only if they exist.

Do you now a reason, why there is no simple find-without-fail or maybeRegister function for those containers?

I have no idea, I’m just a user like you.
But probably because of reliability and reprocability.
A maybeRegister is simply the wrong thing to do in terms of reliable and consistent build, as it behaves differently depending on situation.
If plugin A happens to be applied before plugin B (which always adds the task), the task would be registered and then when B is applied it fails.
If plugin B happens to be applied before plugin A, the task would not be registered.
This is a very bad pattern and also one of the reasons I said “I’m still not sure whether your general tactic is a good one”.

Using getNames feels a bit awkward.

Probably because you are doing something awkward. :slight_smile:
There should only be quite rare edge cases where you need to use it.

Therefore, I need to configure or extend the configuration of those tasks only if they exist.

Then as I said, for example:

tasks.named { it == "..." }.configureEach { ... }

tasks.named { it == "..." }.configureEach { ... } indeed solves most of my use cases.
There is still one case left where I need to check if the task exists or if it must be created. You made me think it through, but I decided, it is the most straight forward solution in my case to do it this way (although there are other ways, as always).
However, I am fine with it now.

Thank you very much for the support!

1 Like