Using Gradle Composite Builds as a BuildSrc Replacement
Article Summary
Yury from Bumble Tech tackles a painful Gradle problem: buildSrc invalidates your entire build cache with every change. Here's how composite builds solve it without sacrificing IDE support.
The Bumble engineering team shares their migration from Gradle's buildSrc to composite builds. This deep dive explains why buildSrc's cache invalidation becomes a major bottleneck for large multi-module Android projects and provides a practical migration path that preserves autocompletion and type safety.
Key Takeaways
- buildSrc changes invalidate entire build cache, even for unaffected tasks
- Composite builds treat plugins as external dependencies, preserving cache
- Migration involves extracting buildSrc to separate included builds with plugins
- Autocompletion works identically using plugins block and extension approach
- Main tradeoff: plugin application order matters more than with buildSrc
Composite builds eliminate buildSrc's cache invalidation problem while maintaining full IDE support, dramatically improving build times for large modular projects.
About This Article
Yury's team found that any bytecode change in buildSrc invalidates the build cache for all downstream tasks, even when inputs and outputs haven't changed. This slows down builds significantly for projects with hundreds of modules.
They switched to Gradle composite builds by extracting buildSrc into separate included builds with custom plugins. This treats configuration logic as an external dependency instead of part of the build classpath.
Gradle can now correctly check task inputs and outputs against cache keys. Unaffected tasks return FROM-CACHE results instead of running again, and the plugins block still provides full autocompletion and IDE support.