Gradle for Scala monorepo. Box experience with 360+ modules

Box migrated its 360-plus-module Scala monorepo from sbt to Gradle between 2015 and 2023 because its existing sbt 0.13 setup produced slow local builds, lengthy CI feedback cycles, and poor alignment with the company’s Gradle-based security, compliance, release, and deployment infrastructure. Gradle improved performance primarily through remote build caching and partial-build capabilities, reducing typical pull-request validation to about 12 minutes and allowing developers and language servers to load only relevant modules, while retaining Zinc, sbt’s incremental Scala compiler, for compilation itself. The transition was costly because services could move only after their full dependency closures were converted, leaving more than 100 modules temporarily maintaining both sbt and Gradle definitions and requiring a dedicated migration team. Gradle also lacked many Scala-specific features supplied by sbt’s ecosystem, so Box built and continues to maintain custom integrations for code generation, build metadata, testing, reporting, compiler plugins, cross-building, publishing, and Scala-aware tooling. Cross-version Scala dependencies and publishing proved especially difficult because Gradle does not natively model Scala binary versions, while coverage based on JaCoCo required exclusions to account for Scala-generated bytecode. Although newer tools, including sbt 2.0, now address some of the caching limitations that originally motivated the move, Box concludes that build-tool decisions should reflect an organization’s broader platform integration needs, migration capacity, and willingness to maintain language-specific gaps rather than treating Gradle as universally superior to sbt.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.