I am registering tasks to build demos. These are optionally added, so they might or might not exist. So I can't rely on them being there. I would like to call the task at the root. e.g.

buildMyDemo

and have it find any

buildMyDemo

tasks in the subprojects and execute them. I have come up with two solutions: Option 1: 1. Register

buildMyDemo

in every project 2. Configure

buildMyDemo

when necessary in the appropriate subproject Option 2: 1. Register

buildMyDemo

in the rootProject once 2. Configure

buildMyDemo

when necessary in the appropriate subproject My question comes down to performance. How much worse is Option 1 vs 2? I have ~800 subprojects. I'm planning on implementing Option 2, but I wanted to understand the impact of

register

across all of the projects.

How about doing neither? Just have the task in the projects where you have it and that's it. If you do

./gradlew buildMyDemo

, each project that does have such a task will get that task executed, the others not.

How about doing neither?

Just have the task in the projects where you have it and that's it.

If you do

./gradlew buildMyDemo

, each project that does have such a task will get that task executed, the others not.

But the use case is to call

./gradlew buildMyDemo

at the root project, if none exists then it would fail. I don't want it to fail.

Also, if I understood your "Option 2" correct, it is a no-go anyway.

I got that you want to configure the root project task from the subprojects.

I wasn't clear. I want to create a

buildMyDemo

task in the root project that is essentially a no-op. And then in any other project (not calling the subprojects closure), have them setup the

buildMyDemo

task for their own project if it should.

Ah, I see. The root-project task is just that it does not fail if no project has the task. But maybe the Build should fail in that case to clearly tell the user that he wanted to do something that makes no sense for that build?

I was browsing the code, the act of creating a provider for a no-op task seems that it would incur at least an increase in memory and some additional overhead. I'm going to go w/ not introducing the additional task provider.