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 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 recently 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. Edge cases are still being found and fixed: expect occasional rough spots over the next few months, especially around concurrent workspaces, unusual project shapes, and crash recovery. The CLI surface above the BSP layer is unchanged.

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.