Grouping build tasks

[Arthurm1]

@jdneo Here you've said that multiple target compile tasks are sent in a single run command for performance reasons.

Does this make that much of a difference to performance? It would be handy to have separate tasks (one per build target) because then there would be separate progress listeners and the client could be updated with the compiling status of each individual build target.

[jdneo]

Thank you for raising the discussion @Arthurm1

I haven't seriously benchmarked the performance. My feeling is that:

Assume a Gradle project contains main and test sourceset. Now user wants to build the whole project.

• (anti-spec) run classes testClasses in one task invocation, Gradle will help handling the task dependencies so that task like compileJava runs only once.
• run classes and testClasses in two task invocations. compileJava is invoked twice. Though Gradle has capability to do incremental build and check if a task is out-of-date, so the second invocation will be skipped.

I thought things might be more complicated when a module depends on another.

Do you have any solution for this? BTW I'm not saying that the current implementation is good because I don't want to be anti-spec, it makes trouble for other clients to adopt the server.

[Arthurm1]

I agree with what you're saying that multiple calls to the same task (e.g. compileJava) will occur if the tasks were called separately. I think Gradle is pretty good these days at knowing it doesn't need to run compileJava on the main sourceset twice but I don't know how much time it adds for Gradle to work that out. I'll ask on the Gradle forums.

I think for now it would be good to at least send the progress info for all the build target ids to the client, not just the first one.
If there's a multi-project setup with ProjectC depending on ProjectB depending on ProjectA and the BSP server was told to clean and compile them all then the progress would ideally show ProjectA compiling, then finishing, then ProjectB compiling, then finishing etc.
Currently it would show that all the time was spent compiling ProjectA. A switch to updating all build targets would show that all projects were compiling the whole time - which is marginally better as the user wouldn't think that maybe there's something wrong with their ProjectA.
It's a shame that there seems to be no way of working out what task the progress update from the tooling API relates to.

[Arthurm1]

I've asked here and the answer is that you shouldn't separate compile tasks out as they will interfere with each other.
I think I've worked out a way to associate progress reports with the appropriate build target - I'll submit a PR.