[GRADLE-1793] Tooling API should provide a way to run tasks equivalent to commandline gradle Created: 12/Sep/11  Updated: 15/Apr/14  Resolved: 15/Apr/14

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-4
Fix Version/s: 1.12-rc-1

Type: New Feature
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Fixed Votes: 0


Currently the tooling API only provides a 'lower-level' mechanism for executing specific tasks on specific projects.

However, on the commandline we can execute groups of tasks with a simple command. For example

"gradle cleanEclipse eclipse"

Executes all cleanEclipse tasks on all projects in the project hierarchy.
Then executes all eclipse tasks on all projects in the hierarchy.

In the tooling API there is no equivalent functionality. One can, of course, query the model and find out what all the cleanEclipse and eclipse tasks are then decide on some order to execute them in... and then launch them.

But this is
1) tedious
2) not guaranteed to execute the tasks in the same order the commandline would (so not equivalent)
3) hampered by bug "http://issues.gradle.org/browse/GRADLE-1792" (so impossible for eclipse related tasks)

Comment by Radim Kubacki [ 03/Feb/14 ]

Isn't this the same as GRADLE-2434 ?

Comment by Szczepan Faber [ 04/Feb/14 ]

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

Comment by Attila Kelemen [ 04/Feb/14 ]

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?

Comment by Kris De Volder [ 04/Feb/14 ]

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.

Comment by Attila Kelemen [ 05/Feb/14 ]

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

Comment by Kris De Volder [ 05/Feb/14 ]

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.

Comment by Radim Kubacki [ 05/Feb/14 ]

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).

Generated at Wed Jun 30 12:04:30 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.