# Avoiding dependency hell with Gradle 6

DevFeed: [Avoiding dependency hell with Gradle 6](<https://devfeed.tech/articles/avoiding-dependency-hell-with-gradle-6-24597.md>)

Original publisher: [Read original article](<https://blog.gradle.org/avoiding-dependency-hell-gradle-6>)

Author: Cédric Champeau

Published: 2019-11-11T05:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Dependency management](<https://devfeed.tech/topics/dependency-management.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Graphs](<https://devfeed.tech/topics/graphs.md>), [Scala](<https://devfeed.tech/topics/scala.md>), [Jackson](<https://devfeed.tech/topics/jackson.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [dependency](<https://devfeed.tech/tags/dependency.md>), [dependency-management](<https://devfeed.tech/tags/dependency-management.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [graph](<https://devfeed.tech/tags/graph.md>), [jackson](<https://devfeed.tech/tags/jackson.md>), [scala](<https://devfeed.tech/tags/scala.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

The article explains how Gradle 6 addresses dependency hell in large projects. It describes problems such as incompatible versions, misaligned component dependencies, dynamic upgrades, vulnerable transitive dependencies, unused dependencies, and inconsistent versions across subprojects. Gradle 6 introduces richer module metadata to give dependency resolution more information for detecting and potentially fixing these issues.

## Source excerpt

Dependency hell is a big problem for many teams. The larger the project and its dependency graph, the harder it is to maintain it. The solutions provided by existing dependency management tools are insufficient to effectively deal with this issue. Gradle 6 aims at offering actionable tools that will help deal with these kind of problems, making dependency management more maintainable and reliable. Take, for example, this anonymized dependency graph from a real world project: There are hundreds of different libraries in this graph. Some are internal libraries, some are OSS libraries. A proportion of those modules see several releases a week. In practice, with a graph of this size, there's no way you can avoid typical problems like: 2 components depending on the same module but with different, incompatible, APIs multiple libraries providing the same feature (a single logger API, but you end up with multiple implementations) and more like: dealing with incompatible versions of a runtime (e.g: Scala 2.11 vs Scala 2.12) misaligned dependencies of a component (e.g: Jackson Databind 2.9.0 with Jackson Core 2.9.4) builds suddenly failing because of a dynamic version upgrade (version "1.+") rejecting vulnerable transitive dependencies removing unused dependencies inconsistent versions between subprojects in the same repository Dependency issues can cause many problems when building and testing your products and it can be extremely challenging to figure out, on a daily basis, what caused a regression, why the project suddenly doesn't build anymore or what dependency is responsible for an upgrade of another dependency. If you are lucky, you would get a compile time error, but it's common to only see problems occurring when executing tests or even at production runtime. In all these cases the error is often hard to trace back to the source, as it appears after the dependency resolution in the build tool has been successful. So from a dependency management perspective everything