At org scale, curated starters can pull large transitive graphs (bloat, unwanted CVE-carrying jars, duplicate logging bindings). How do you keep dependency hygiene while still benefiting from starters?

## The tension Starters trade **breadth for convenience**: one coordinate can transitively bring dozens of jars. At one service that's fine; across an org it means larger images, wider CVE surface, and occasional conflicts (two logging bindings, two JSON libs). The principal-level skill is keeping the **alignment guarantee** while controlling the **graph**. ## 1. Centralize version management Create an **internal platform/BOM** module that `import`s `spring-boot-dependencies` (and Spring Cloud's BOM, etc.), pins any org-specific overrides once, and is consumed by every service (Maven `import` scope, or Gradle `platform()/enforcedPlatform()`). Benefits: a CVE bump (e.g., a Jackson or Tomcat security release) is made **once** and propagates; all services stay mutually aligned. Avoid per-service version overrides that fragment the matrix. ## 2. Make the resolved graph visible Starters hide the graph; make it explicit: - `mvn dependency:tree` / `./gradlew dependencies` — see what each starter actually pulls. - **OWASP Dependency-Check** / GitHub Dependabot / Snyk — flag CVE-carrying transitives. - Fail the build on **version conflicts** (`enforcedPlatform`, Maven Enforcer `dependencyConvergence`). ## 3. Prune with exclusions — the canonical logging case `spring-boot-starter` brings **`spring-boot-starter-logging`** (Logback + SLF4J bridges). If you want Log4j2, you add `spring-boot-starter-log4j2` **and exclude** `spring-boot-starter-logging` — otherwise you have **two SLF4J bindings** on the classpath, and SLF4J warns/behaves nondeterministically. This is the textbook example of "a curated set needs surgical exclusion": ```kotlin implementation("org.springframework.boot:spring-boot-starter-web") { exclude(group = "org.springframework.boot", module = "spring-boot-starter-logging") } implementation("org.springframework.boot:spring-boot-starter-log4j2") ``` Similar surgical exclusions: dropping `tomcat-embed` for Jetty, removing an unwanted JSON binding, or excluding a transitive that duplicates something you provide. ## 4. Don't over-include starters in the first place The cheapest hygiene is **not adding** starters you don't need. Because auto-config is **conditional** (`@ConditionalOnClass`), a starter you don't include simply never configures — there's no penalty for omission and a real cost (jars + CVE surface + startup class scanning) for inclusion. Split responsibilities: a batch job doesn't need `spring-boot-starter-web`. ## 5. Watch the compile/runtime scope boundary Starters are usually `implementation`/`compile` scope; that leaks their API onto the consumer's compile classpath. Use Gradle's `implementation` (not `api`) in libraries so a starter you depend on internally doesn't transitively become part of your published API surface. ## 6. Reproducibility Use a **dependency lock** (Gradle dependency locking, Maven via the enforcer + fixed versions) so the resolved graph is reproducible build-to-build — starters + ranges can otherwise drift. ## Gotchas / anti-patterns - **Excluding a jar a starter genuinely needs** — you can break auto-config; verify with the tree, not by guessing. - **Local version override to "fix" a CVE** — prefer bumping the platform/BOM so alignment holds; a lone override can desync the tested matrix. - **Adding both Tomcat and Jetty / Logback and Log4j2** — duplicate providers cause nondeterministic selection or startup errors. - **Treating the starter as the API** — publish narrow APIs; keep starters as an internal implementation detail where possible. ## Bottom line Starters + BOM give **coherence**; org-scale hygiene adds **curation on top**: one shared platform for versions/CVEs, visible + policed graphs, and surgical exclusions where the curated default doesn't fit.