Isn't this the same as GRADLE-2434 ?

Let's keep them separate for now. I think the other one is focused around visualizing those tasks. Feel free to close them both once you finish the story

As much as I understand this issue, this actually works in the Tooling API. If you pass the "build" task for the root project, build will be run for each subprojects as well. There is certainly no need to pass qualified task names for each projects (and this works properly at least since 1.0, I would have certainly noticed if it weren't). Could it be that this issue has already been fixed prior releasing 1.0?

Re Atilla's comment. I have tested this and he is right. Simply using task names like 'build' instead of ':build' or longer qualified task names and passing these to the tooling API works now.

Even if this is the case there used to be a very good reason why STS always uses these qualified names to execute any task: http://issues.gradle.org/browse/GRADLE-1793

That issue is also reportedly fixed. So it should be ok to remove the workaround from STS and use non-qualified task names to execute task across a hierarchy.

I think that means that both GRADLE-1793 and GRADLE-2434 can be closed.

Possible caveat: One remaining thing that might still be useful is api to discover agregagated task names that are valid at a given project.
I.e. if I point to some multiproject and some of its subprojects define a task called 'foo' then, even though the project itself may not define 'foo' a request for all agregated tasks on the parent project should include some representation of the aggregated 'foo' task.

I can of course relatively easily discover all those valid names myself by walking the hierarchy and I'm ok with doing that, unless there are some concerns from your side that the algorithm for computing agregated tasks might be more complex than this and/or changing in future versions of gradle.

GRADLE-2434 was treated as your "possible caveat". Take a look at these changes:

• GradleProject.getTaskSelectors: https://github.com/gradle/gradle/blob/master/subprojects/tooling-api/src/main/java/org/gradle/tooling/model/GradleProject.java#L84
• BuildLauncher.forTasks: https://github.com/gradle/gradle/blob/master/subprojects/tooling-api/src/main/java/org/gradle/tooling/BuildLauncher.java#L85-L95

Thanks for those pointers. They are very helpful.
You can close this issue and I agree with the interpretation of Gradle-2434 being about discovering aggregated tasks.

There are some corner cases still where a build performed from command line is not easy to reproduce using Tooling API: you can launch build using 'build' as task name and IMO it will use project directory passed to GradleConnector. We will add a way to discover these 'aggregated tasks'/'task selectors' and these will be associated with a Gradle project (project directory).