Gradle Dependency Management Explained

Gradle's dependency management system is built around configurations — named classpaths with specific semantics. The key insight is that implementation versus api is not just a naming convention; it controls compilation scope and build performance.

`implementation` vs `api` — the most important distinction

• implementation keeps a dependency internal — downstream modules cannot accidentally import it; changing an implementation dependency only recompiles the declaring module
• api exposes a dependency publicly — its types appear in the declaring module's public method signatures, and downstream modules can use it; any version change forces recompilation of every downstream module
• The practical rule: default to implementation everywhere; switch to api only when the compiler tells you a downstream module needs access to the types — overusing api defeats the entire configuration system and causes unnecessary recompilation cascades

Version conflict resolution

• Gradle's default strategy selects the highest requested version when two dependencies request different versions of the same library — safer than Maven's nearest-definition-wins rule which can silently downgrade
• Version catalogs in libs.versions.toml centralize all coordinates in one file — libs.versions.jackson = "2.16.1" referenced across all modules ensures consistent versions without duplication
• resolutionStrategy.force("com.example:library:1.2.3") pins a specific version regardless of what other dependencies request — use sparingly; it can mask legitimate version conflicts

Dependency analysis

• ./gradlew dependencies --configuration runtimeClasspath shows the full resolved dependency tree for the artifact that ships
• The com.github.ben-manes.versions plugin adds ./gradlew dependencyUpdates which reports which dependencies have newer versions available — useful for regular dependency hygiene