Skip to content

SYSTEM Cited by 1 source

Build Server Protocol (BSP)

The Build Server Protocol (BSP) is a standardized protocol between a build tool (the build server) and a language server / IDE (the client), analogous to LSP but for build information: project structure, dependencies, classpaths, compile diagnostics, generated sources, test discovery, and debug launchers. It lets a language server ask the build system "what is the project model?" without hard-coding a specific build tool. (Source: sources/2026-08-11-databricks-open-sourcing-metals-v2)

The v1 coupling problem

Metals v1 put the build server on the editor hot path: it waited for BSP to supply the initial project model at startup and used the build server for diagnostics during editing. At monorepo scale this is fatal for TTII — the editor is useless until the build system responds, and background sync competes with developer builds for the build lock.

Metals v2's narrower contract

Metals v2 still uses BSP, but with a narrower contract (metadata-first-build-integration):

  • Routine diagnostics move out of the build server into the compiler pipelines (which read a Metals-provided sourcepath / the mbt index).
  • BSP is used mostly to query build metadata: dependencies, generated sources, test discovery, debug launchers — the long tail that genuinely needs build-graph fidelity (e.g. navigation into third-party deps or generated code, respecting custom shading rules).

This shift lowers the barrier to implementing a BSP server for Metals v2. Databricks' production BSP server is an internal Go implementation tailored to its Bazel rules, querying 285k Bazel JVM targets at editor latencies (not part of the OSS release). Design choices worth carrying over:

  • Never invoke Bazel unless the user explicitly asks — build sync is an explicit user action, never startup behavior or background maintenance, so it doesn't take the Bazel lock and compete with developer builds.
  • Metadata stored in a JSON snapshot that scales via constant pooling for repeated labels, paths, and repository prefixes; users incrementally add targets on sync.
  • No shared sync configuration format — users sync individual files / directories on demand, because predefined sync sets grow, get copied between teams, and become slower than the focused sync a developer actually needs.

Seen in

Last updated · 766 distilled / 2,225 read