Skip to main content

Project status

Bleep exists because the existing JVM build tools couldn't keep up with the codebases we needed to ship. Maven, Gradle, and sbt all slow to a crawl on multi-hundred-thousand-line builds — import in IntelliJ takes minutes, incremental compiles stall on configuration overhead, and every CI run pays the JVM startup tax. Bleep is shaped for enormous codebases from the start: a flat YAML model, an in-process BSP server, native-image CLI startup, per-project locks, and an incremental compile loop tuned for projects with thousands of source files.

It self-hosts — bleep itself is built with bleep, including a multi-project Scala 3 codebase, several ported sbt plugins, and the GraalVM native-image release pipeline. It's also in production on private codebases with millions of lines of source, plus libraries published to Maven Central, generated-source projects with hundreds of thousands of lines, and backend services shipping to real users.

The workload bleep is developed against​

The daily driver is a private repository of 12.9M lines across 57,941 files. Of that, bleep compiles 4.1M lines of Java and Scala across 11,896 files in 67 projects — and 3.7M of those Java lines (92%) are generated and checked in, a SQL parser and AST family spanning a dozen database dialects. Roughly 2,300 declared tests run against a corpus of 44,127 SQL files, and several suites are heavy enough to need their own heap.

It is never one build at a time. Development runs across a dozen or more git worktrees concurrently, each an independent client of the same shared compile server, often driven by several agents at once. A single diagnostic session on that setup caught the daemon serving 11 worktrees across 14 concurrent connections and 18 concurrent compiles.

That shape is why bleep is built the way it is, and it is where its bugs come from. A shared daemon that keeps a dozen worktrees warm is what parallel development at this scale needs; it is also the thing that has to stay correct under contention before it is worth anything.

The version is 1.0.0-M*, milestone, not GA. The build model is stable in practice; named features are tested by integration tests.

The bleep-bsp rewrite​

The compile server (bleep-bsp) was rewritten with heavy Claude assistance — BSP protocol handling, Zinc invocation, the per-project lock model, the shared-daemon lifecycle, the test runner. Core paths are tested and the rewrite is what powers the bleep build itself today. The CLI surface above the BSP layer is unchanged.

1.0.0-M11 is largely the release that went and found those edge cases. Its 83 commits are dominated by exactly the areas flagged here as rough: concurrent workspaces (one client's disconnect no longer kills another's forks; locks and KSP mutexes are scoped correctly), scheduling under contention (one machine-wide governor, three reproduced deadlocks fixed, every fork bounded), heap retention (Zinc analyses interned and owned by their workspace), crash recovery (readiness by connect rather than by grepping a rotated log, idle self-shutdown, logs that survive the restart meant to diagnose them), and a family of bugs that let a broken build report success. See the M11 release notes.

Expect occasional rough spots still — this is milestone software and the surface is wide — but the specific failure modes that motivated this warning have mostly been closed rather than merely acknowledged.

If you hit a bleep-bsp issue, the server log at ~/Library/Caches/build.bleep/socket/<hash>/output (or the equivalent on Linux) is the first thing to attach to a bug report.

What's not yet covered​

  • No BOM / dependencyManagement: every dependency declares its version explicitly. Spring Boot users feel this most.
  • No KAPT for Kotlin. KAPT is legacy; migrate to KSP1, which is supported (see annotation processing). KSP runs from scratch on every compile today; per-file change tracking for incremental mode is a planned follow-up.
  • No Gradle import: Maven and sbt are imported via bleep import / bleep import-maven.
  • Single-host caching only: remote cache works via bleep remote-cache pull / push; not transparent on every invocation.
  • Plugin ecosystem is small compared to Maven/Gradle/sbt, the ports that exist (sbt-ci-release, sbt-sonatype, sbt-pgp, sbt-dynver, sbt-native-image, sbt-scalafix, sbt-jni, mdoc) cover release workflows; one-off plugins are user-implemented as scripts.

Recommendation​

Use bleep on greenfield projects without reservation. For migrating an existing build, run bleep import or bleep import-maven first , if the imported result compiles and tests, you're in a usable state.