IDE (VSC) "Support" via CLI/Bazel Rule (?) which just writes/updates respective configuration file

[vorburger]

Given the various issues I'm facing, I was wondering if at least initially looking more closely into a more simple and basic Bazel Java VSC integration than full-blows VSC extensions in JS/TS and an OSGi plugin loaded dynamically into the JDT of the redhat.java VSC extension...

The architectures above are all lots of fun, of course, but wouldn't be the lowest hanging fruit, and the easiest to work with, be some sort of trivial CLI, possibly easily consumable via a bazel run in any project, which (literally) JUST updates in .vscode/settings.json? Because that is really all one ultimately needs from all this (I think).

The BazelAnalyzerApp looks like it has most of what's needed for that - just missing a thingie that writes java.project.referencedLibraries to .vscode/settings.json, which should be relatively trivial to code?

If I can make the time, perhaps I'll explore this.

[vorburger]

The BazelAnalyzerApp looks like it has most of what's needed for that - just missing a thingie that writes java.project.referencedLibraries to .vscode/settings.json, which should be relatively trivial to code?

After a closer look, I'm starting to understand that's not quite it; instead, one would need to build a JvmUnionClasspath (from which JvmClasspathData with JvmClasspathEntry[] can then be obtained) - similar to how the BazelClasspathContainer in bazel-eclipse does it.

An additional example App illustrating how to do this (in a standalone App, outside of and without directly depending on Eclipse JDT) could be a useful start.

[vorburger]

I'm currently manually downloading JARs and adding them to VSC Classpath Configuration to explore doing this.

It would be neat to be able to use this approach to "bootstrap" working on this project itself...

[vorburger]

https://github.com/salesforce/bazel-java-sdk/compare/master...vorburger:bazel-java-sdk:issue-47

[guw]

The idea of the Java SDK is to allow writing such a CLI. The Java LS is essentially a headless Eclipse. If the JDT.LS folks are open to it I would like to embed it directly into the language server.

However, I am not sure about the benefits of a CLI. It would be pretty inflexible. The idea is that people can use a .bazelproject file to control the visibility inside IDEs. Any modification to the project view would require re-running the CLI. IDEs typically compute the classpath dynamically. Eclipse JDT uses the concept of a classpath computation (which I am currently refactoring heavily https://github.com/salesforce/bazel-eclipse/pull/444).

But the principle is running a bazel build with aspect to get a dump of the classpath. You could then also convert that dump into anything you want. https://github.com/salesforce/bazel-java-sdk/blob/af3d6d3b6a713564a204bda5de89461c2583a2da/sdk/bazel-java-sdk/aspect/intellij_info_impl.bzl#L559