How does Gradle handle transitive dependency resolution?

When a declared dependency itself depends on other libraries, Gradle pulls those transitive dependencies in automatically, recursively, building a full dependency graph rather than just the directly-declared set. Each node in that graph carries its own transitive requirements, and Gradle merges the whole thing into a single resolved set per configuration, applying conflict resolution (by default, highest version wins) wherever the same library appears more than once.

./gradlew dependencies --configuration runtimeClasspath

Groovy DSL's implementation vs api distinction directly controls what leaks transitively to consumers: an api dependency of a library becomes a transitive compile-time dependency for anyone using that library, while an implementation dependency stays internal and isn't exposed. Unwanted transitive dependencies can be removed with exclude group: '...', module: '...', and Gradle's dependencies task (or dependencyInsight for a specific library) is the standard way to actually see the resolved tree and understand where a given transitive dependency is coming from.