BazelCon 2019 Day 2: Half-Day Bazel Bootcamp (Part 2)

Overview

This is part 2 of a half-day Bazel bootcamp at BazelCon 2019, walking attendees through progressively complex build scenarios using Bazel, Google's open-source build system. The presenter takes a hands-on approach, starting with simple Java examples and building toward multi-language projects and full-stack development.

Key Topics

**Java Builds and Testing** The session opens with basic Java compilation and testing. Key learning points include understanding test command defaults (designed for monorepos with thousands of tests), using flags like `--test_timeout` and `--test_output=all` to debug failing tests, and understanding Bazel's output directory structure. The speaker explains symlinks created by Bazel (bin, out, test logs) and how generated bash wrappers handle Java invocations, noting that this can replace hand-coded command-line wrappers.

**External Dependencies** The presenter covers the HTTP jar mechanism for simple cases, then moves to Maven-based dependency resolution using rules_jvm_external. Maven artifact pinning is demonstrated as essential for reproducibility. The concept of the single version policy (picking one version of each dependency company-wide) is introduced as Bazel's preferred approach, though acknowledged as not always practical.

**Multi-Language Projects (Java + Go + gRPC)** A 183-line workspace file example shows how to integrate Java and Go in a single project using Protocol Buffers and gRPC for type-safe cross-language communication. The workspace must explicitly load rules for protocol buffers, gRPC bindings for both Java and Go, Maven support, and the Go toolchain. The complexity grows not with project size but with the number of different technologies used. A working example demonstrates a Go frontend calling a Java backend service via gRPC to fetch a grocery list.

**Extending Bazel with Macros** The presenter introduces macros as a gentle entry point to Bazel extensibility—simple functions that wrap and standardize multiple rules. An example shows creating an "Acme Corporation gRPC macro" that encodes naming conventions and eliminates boilerplate. This bridges from consuming rules to eventually writing custom rules.

**Full-Stack Development** The workspace configuration for a JavaScript/Java project reveals additional complexity: npm/yarn integration, symlinks exposing node_modules to IDEs, and a double-layer dependency mechanism where Bazel rules are published to npm and then consumed from npm. The npm ecosystem's shallow package granularity and large transitive dependency trees (400–700+ MB) are noted as different from Maven's structure.

Takeaways

- Workspace file complexity depends on *how many technologies* are in use, not on the amount of code per technology - Bazel's design strongly favors single-version dependency policies and monorepo structures, though workarounds exist for multi-repo scenarios - IDE integration remains a limitation; Maven pom generation from Bazel files is a current workaround - Macros are the practical entry point for extending Bazel; they precede writing full custom rules - Multi-language projects require careful workspace setup but then scale well: adding 25 more microservices may require no workspace changes - Federation (a coming Bazel feature) is expected to dramatically simplify workspace configuration by automatically resolving compatible versions