Gradle lsp#275
Open
tartarughina wants to merge 7 commits into
Open
Conversation
This commit introduces comprehensive Gradle build file intelligence to the Zed Java extension: - **gradle-lsp-bridge** (`gradle-bridge/`): A new native binary that bridges LSP (stdio) to the Microsoft Gradle Language Server (Unix socket / Windows named pipe) and drives the shipped `gradle-server.jar` over gRPC. This provides plugin-aware completions, closures, and build-script diagnostics. Build outcomes (successful models or evaluation errors) surface as diagnostics merged with the language server's syntax errors. - **proxy-common**: Extracted shared primitives (LSP framing, parent-process monitor) into a new workspace crate, eliminating duplication between `java-lsp-proxy` and `gradle-lsp-bridge`. - **gradle-sync workflow**: At server initialization and on every save of a Gradle build file or `gradle-wrapper.properties`, the bridge performs a `GetBuild` RPC to a long-lived, warm `gradle-server` process, coalescing bursts into a single pending rerun. The resulting model (plugins, closures, script classpaths) is forwarded to the language server via `workspace/executeCommand`, matching the VS Code extension's contract. - **Groovy grammar**: Added `tree-sitter-groovy` to support `.gradle` / `.gradle.kts` syntax highlighting and queries. - **GradleLs component**: Downloads the Gradle Language Server from the VS Code extension VSIX. - **GradleBridge component**: Downloads the `gradle-lsp-bridge` binary as a per-platform asset alongside the JDTLS proxy. - **Language registration**: `gradle` language (`.gradle` files) is now recognized and configured.
Move `parse_content_length`, `lsp_body`, and `contains_subslice` from gradle-bridge into proxy-common's lsp module so both the proxy and gradle-bridge can share the same LSP framing logic. Add comprehensive unit tests covering edge cases and frame parsing.
Consolidate duplicate platform detection logic in `proxy.rs` and `gradle_bridge.rs` into two shared helpers: `platform_exec_name` and `platform_asset_name`. Both functions live in `util.rs` and handle OS/arch mapping, file extensions, and `.exe` suffixes consistently. Also remove explanatory comments from `gradle_ls_server.rs` that merely restate the code.
Remove duplicate install path strings (`"proxy-bin"` and `"gradle-bridge-bin"`) and replace with a shared `NATIVE_BIN_DIR` constant set to `"bin"`. Both the proxy and Gradle bridge are versioned together and can safely co-locate in the same directory.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add Gradle Language Server support (gRPC-driven build model)
Summary
Adds Gradle build-file intelligence to the extension via Microsoft's Gradle Language Server, driven the same way the official VS Code Gradle extension drives it, by running the bundled
gradle-serverover gRPC. A new native binary,gradle-lsp-bridge, sits between Zed and the language server: it keeps a singlegradle-serverprocess (and its Gradle daemon) warm for the session, resolves the build model, and feeds it to the LS.For Groovy
.gradlescripts this gives plugin-aware completions (closures, plugin-contributed blocks likejava {}/application {}), Maven Central dependency coordinates, and diagnostics. For Kotlin.gradle.ktsscripts it provides syntax highlighting plus build-evaluation diagnostics (see below).Kotlin DSL handling
The Gradle Language Server is Groovy-only (it can't parse Kotlin), so
.gradle.ktsdoesn't get completions. Butgradle-serveritself runs Gradle's Kotlin-DSL compiler during configuration and emits real errors with file/line, the bridge captures these and surfaces them as editor diagnostics, which VS Code only logs. The Groovy LS's own (invalid) diagnostics for.gradle.ktsare suppressed. Highlighting uses the bundled Kotlin grammar via a dedicatedGradle KTSlanguage, scoped by longest-suffix-match so plain.ktfiles are unaffected.Architecture / refactors included
proxy-commoncrate extracted: shared LSP framing + parent-process monitor +file://URI helper, used by both native binaries (keeps the JDTLS proxy lean: no async/gRPC stack leaks into it).gradle-lsp-bridgebuilt as a separate binary (tokio/tonic/prost), so the gRPC dependency tree stays out ofjava-lsp-proxy.Downloadable,LanguageServer) so the new server type and binary slot in cleanly;java.rsdispatch simplified.Configuration
Gradle settings live under the
gradle-language-serverLSP block (separate fromjdtls). All optional works out of the box. Notablyjava_homecontrols the JDK the Gradle daemon uses (17+); it's configured per-server and falls back to$JAVA_HOME. Full reference in the README's new Gradle Build Files section.Distribution
CI builds and ships
gradle-lsp-bridge-<os>-<arch>assets alongside the proxy on the same release tag, across the existing 6-target matrix.Testing
wasm32-wasip1extension target.