Solving Poly-Repo Dependency Nightmares
summary
SumUp confronts polyrepo dependency drift by building Gradle tooling: custom build-logic repo and published settings plugins that generate version catalogs, plus automation to publish, snapshot and announce updates. Initial lowest‑level approach fails — concurrent untested publishes and TOML/Gradle limitations — so the team moves the authoritative centralized version catalog into the main Superapp project. Result: app vs POS SDK version conflicts are resolved before build via enforced constraints and resolution strategies, single-PR updates for shared libs, and reproducible dependency resolution across repos.
AI-written summary · about
chapters (15)
- 0:00Poly-repo dependency challenges
- 2:13Monolith vs monorepo vs polyrepo
- 4:19Polyrepo dependency integration
- 6:05Complexity in polyrepo setups
- 8:32SumUp’s dependency architecture
- 10:58Dependency conflicts and Gradle
- 13:27Forcing dependency versions in Gradle
- 15:33Centralizing dependencies with catalogs
- 17:20Gradle plugins for dependency
- 22:16Publishing version catalogs
- 24:02Unified dependency management goals
- 25:26Shared build logic repository
- 28:57Refining version catalog approach
- 30:20Developer experience improvements
- 32:06Final solution and benefits
related talks
19mEscaping Chaos: Strategies to Move from Polyrepo to Monorepo
35mThe Gentle Monorepo - Ship Faster and Collaborate Better
24mMonorepo Madness: Dependencies, License Compliance, and Automation
33mTools of the Trade
36mNasty Dependencies: Surviving and fixing bugs in 3rd-party libra…
19mKeynote: Why Monorepos
24mBuilding your ideal codebase: monorepos & multirepos living in harmony
16mManaging multiple packages in a monorepo