I was searching for this but did not find any info in any of the issue trackers or docs. Does anyone know about the status/plans of supporting

org.gradle.unsafe.isolated-projects

in VS Code? Currently they add an init script that causes issues like

':app' cannot access 'Project.tasks' functionality on another project ':'

Just a wild guess, but maybe no VSC user tried it yet and reported a problem so maybe they are not aware that something needs to be changed as there is no issue for it. 🤷‍♂️

which extension are you talking about here? the fwcd kotlin lsp plugin has general configuration cache incompatibility in the init script like you mention. the beta official jetbrains kotlin lsp for vsc does work with configuration cache, though i havent tried with isolated projects yet

Just the standard Gradle for Java extension. The issue happens when I import the project or run a task though the Gradle view. Is there an alternative to working with Gradle in VS Code? The only feature I really need is a view where a user sees all the available subprojects and tasks in a tree and can start any task from there.

i'm not aware of one.

I did some analysis and created an issue: https://github.com/microsoft/vscode-gradle/issues/1713 Is there some guidance for "IDE Vendors" (i.e. Tooling API Users) how to adjust their Module Building to no longer use cross-projects APIs that I could link to in the issue?

I guess just https://docs.gradle.org/current/userguide/isolated_projects.html

We don’t have dedicated docs for this yet, but there is a somewhat recommended path around fixing the Model Building compatibility. The constraints for model builders are exactly the same as for any other configuration-time logic — you are not allowed to touch mutable state of other projects, for all the same reasons.

Project.tasks

is a mutable container of the root project accessed from the child, and that’s why it fails. This seems like a subproject needs to know something about its parent. So we’d need to learn what they are trying to do. The main problem that IDEA faced when making sync IP compatible is implementing aggregation. Historically, there always was the root-project model builder that walked all subprojects to extract data. That is not IP compatible. The solution is to split the “main” model builder and the per-project model builders. The aggregation is then done by running nested build actions via BuildController.run — it’s IP safe and can even run the nested actions in parallel.

Thanks @Alex Semin. I had a look at the implementation and I don't think they do anything fancy or unusual. It should be basically this:

Historically, there always was the root-project model builder that walked all subprojects to extract data.

I will share the solution you described in the issue.