Regarding the issue of syncing external dependencies in VScode

[hsjdhudn]

When developing Java projects managed by Bazel in VSCode, external Maven dependencies declared via maven.install(rules_jvm_external) or Bzlmod are consistently flagged as "not found" or "unknown packages" in the editor (displayed with red error underlines). Code completion, navigation, and other intelligent features fail for these dependencies. However, the project can be built and run successfully via bazel build, and the dependencies are correctly downloaded to the Bazel cache. The same project works perfectly in IntelliJ IDEA (using the official Bazel plugin), with all dependencies recognized correctly.

Core Symptoms:

In VSCode:​ importstatements show errors, e.g., "Cannot resolve symbol 'XXX'".

Actual Build:​ The bazel build //...command succeeds, proving dependencies are present and correctly linked.

Comparative Test:​ No such issue occurs in IntelliJ IDEA; dependency recognition works normally.

Root Cause Analysis:

This is not a configuration error but a toolchain gap in the VSCode extension ecosystem.

Separation of Responsibilities:​ The core engine providing Java intelligence is the "Language Support for Java(TM) by Red Hat"​ extension. It relies on a project model to obtain the classpath.

Support Limitation:​ This Red Hat Java extension is primarily designed to parse standard Maven (pom.xml)​ and Gradle (build.gradle)​ project models. It lacks built-in capability​ to parse Bazel-specific dependency declaration files (e.g., maven.install rules in MODULE.bazel or WORKSPACE).

Broken Information Flow:​ While the "Bazel" extension handles build tasks, its current version (0.13.2) does not appear to synchronize the precise dependency list and JAR file paths calculated by Bazel with the Red Hat Java language server. Consequently, the language server "cannot see" these downloaded dependencies, leading to errors.

Contrast with Working Cases:​ The Maven for Javaand Gradle for Javaextensions succeed because they are specifically responsible​ for translating and injecting​ their respective build system's project model and dependency paths into the Red Hat Java language server. The Bazel extension currently lacks this crucial "adapter layer".

Environment Information:

OS:​ Windows 11 Pro 23H2

Editor:​ TRAE CN V3.3.37 (VSCode-based)

Build Tool:​ Bazel 9.0.0

Relevant Extensions:

Bazel: 0.13.2

Language Support for Java(TM) by Red Hat: 1.53.0

Maven for Java: 0.45.1

Extension Pack for Java: 0.30.5

[cbandera]

Thank you for opening this issue. Do I understand correct, that the red squiggles that you see are in Java files and not in starlark files?

So as described in you root cause analysis, the problem is about bridging the gap from the language agnostic build system, to language specific tools and extensions.

We had a similar discussion before when discussing compile_commands.json support to enable C++ tooling. Back then the argumentation was that this vscode extension is only concerned with enabling the work with the bazel build system and starlark. Supporting specific programming languages is out of scope.

I understand that other IDEs support this, but it would be unfeasible to support all (or even the major) programming languages as part of this community provided extension. But maybe the integration that you are looking for could be provided by a separate extension?

[hsjdhudn]

Your summary of the core issue is spot on—this is indeed the challenge of bridging the gap between a language-agnostic build system (Bazel) and a language-specific toolchain (Red Hat Java Language Server).

Below are two possible paths forward for your and the community’s consideration:

Option 1: Develop a standalone “Bazel Language Support” extension (Recommended)

This approach best aligns with the principles of modular design. A standalone extension can focus on addressing integration issues for languages like Java:

Core Functionality: Invoke bazel query or similar commands to parse the project’s dependency graph and generate standard classpath information.

Bridge Function: Using Java as an example: Convert the above information into a format recognizable by the Red Hat Java extension (e.g., configuring java.project.referencedLibraries) and dynamically inject it.

Advantages: Clear separation of responsibilities, decoupled from existing Bazel extensions, and easier to maintain and iterate. Other languages (such as Kotlin and Scala) could also follow this pattern to develop corresponding extensions in the future.

Option 2: Provide extensible “hooks” or foundational support within the Bazel extension

If the Bazel extension plans to offer a more general-purpose language integration framework in the future, it could:

Provide an API or protocol: Allow third-party extensions (such as the Java support extension) to query project structure, dependencies, and other metadata from the Bazel extension.

Generate standard files: Have Bazel extensions generate intermediate files containing build information (such as a Java equivalent of compile_commands.json), which other extensions can then read and process.

Will this feature be supported in 0.14.0?