Better requests organization

[CsCherrYY]

Currently, we have two requests to get something from the Gradle build:

• GetBuild
• GetProjects

When the build file changes, the request GetBuild and GetProjects will be called both. GetBuild is used to get some information (mostly tasks) of a root project and GetProjects is used to get some information of a specific project (can be a subproject). They have some similar process and might be optimized. Since opening a new connection will use more resources than using an existing one, and getting the project content has less resource requirement, I'll try to find a way to optimize it.

The time when we call GetBuild requests:

• One of the child project's build files has been changed.
• user manually refresh

The time when we call GetProjects requests:

• The current project's build file has been changed.
• user manually refresh

If we merge these two requests and make some changes to them, we can obtain

• better performance, since we can get all information via one TAPI request
• less resource consumption (only one connection per workspace folder)
• clear and readable code

we will do the following steps:

• get tasks via custom model, instead of TAPI default model feat: Get tasks from custom tapi model #1148
• get debug tasks list, it will fix or supersede feat: Automatically detect debug tasks #1149
  • Use custom model & plugin to get more detailed tasks info #394
  • Working example with task debugging? #1118
  • Surface debug tasks #398
  • feat: Support automatically detect debug tasks #1138
• merge two requests into one feat: Merge getBuild and getProject requests #1152

[CsCherrYY]

The current structure is

The drawback is we will frequently change the GradleConnector directory of tooling API, which causes a lot of Gradle daemon stop/start when the project has multiple modules. So we plan to use this model:

In this model the GradleConnector will always for the workspace folder directory, and we can specific the project folder and use ParameterizedToolingModelBuilder to avoid fetching useless information. All the information will come from request getBuild().

And the remaining problem is the Gradle Connector mechanism, about when to create a new daemon and how to cache the existing daemons (or whether we need to do this). If the number of opened workspaces is more than one, should we have some caches to store the existing GradleConnector?

cc @donat for suggestions and comments about the Gradle daemon mechanism.