# Automatically align Dependencies with Platforms and Gradle Module Metadata

DevFeed: [Automatically align Dependencies with Platforms and Gradle Module Metadata](<https://devfeed.tech/articles/automatically-align-dependencies-with-platforms-and-gradle-module-metadata-24593.md>)

Original publisher: [Read original article](<https://blog.gradle.org/alignment-with-gradle-module-metadata>)

Author: Jendrik Johannes

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

Content type: article

Language: en

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

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

Tags: [alignment](<https://devfeed.tech/tags/alignment.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [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>), [jvm](<https://devfeed.tech/tags/jvm.md>), [libraries](<https://devfeed.tech/tags/libraries.md>), [library](<https://devfeed.tech/tags/library.md>), [module](<https://devfeed.tech/tags/module.md>), [platforms](<https://devfeed.tech/tags/platforms.md>)

## AI overview

This Gradle article explains how dependency conflicts can produce inconsistent versions across related library modules. Using Jackson as an example, it describes how Gradle Module Metadata and platforms can express alignment information so that modules are upgraded together, while noting the limitations and maintenance costs of relying on BOMs alone.

## Source excerpt

This blogpost has been updated to reflect that Jackson started to published Gradle Module Metadata with version 2.12.0 using the recommendations from this post. In the previous post about dependency management with Gradle 6, we saw that growing builds can quickly end up in dependency hell. Unexpected results become particularly hard to analyze if they are introduced at the bottom of the dependency graph and propagate up through transitive dependencies. It is unfortunate that some of these issues could be avoided if the authors of libraries, which form the bottom of the dependency graph, had the means to express all the knowledge about the versioning of said libraries in the libraries' metadata. A typical example of such a library is the widely used JVM utility library Jackson. If several components of the library are part of the dependency graph, alignment of versions can be an issue. The Jackson library is made up of only three core modules: jackson-annotations, jackson-core and jackson-databind. Still, it is easily possible to end up in a situation where a higher version is selected for jackson-core than for jackson-databind. This situation is illustrated in the following example, where the two modules end up having different versions: jackson-core:2.9.2 and jackson-databind:2.8.9. In the example, which you can explore as a build scan, one transitive dependency (tika-parsers) upgraded jackson-core to 2.9.2 as Gradle resolves the conflict between 2.8.9 and 2.9.2 to the higher version. jackson-databind however, added via another dependency (keycloak-core), is kept on 2.8.9 as the information that it should be aligned, i.e. upgraded together, with jackson-core is missing. BOMs are great, but we don't use them (enough) The situation we face in this scenario is that the Jackson modules' versions should be aligned, but that information is not published due to limitations of the pom metadata format. What Jackson is publishing is a BOM (bill of materials), a pom.xml conta