# Introducing Gradle Module Metadata

DevFeed: [Introducing Gradle Module Metadata](<https://devfeed.tech/articles/introducing-gradle-module-metadata-24630.md>)

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

Author: Cédric Champeau

Published: 2019-03-07T05: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>), [Java](<https://devfeed.tech/topics/java.md>), [Software](<https://devfeed.tech/topics/software.md>), [Logging](<https://devfeed.tech/topics/logging.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [binaries](<https://devfeed.tech/tags/binaries.md>), [build-tool](<https://devfeed.tech/tags/build-tool.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency-management](<https://devfeed.tech/tags/dependency-management.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [java](<https://devfeed.tech/tags/java.md>), [logging](<https://devfeed.tech/tags/logging.md>)

## AI overview

The article introduces Gradle Module Metadata 1.0, released with Gradle 5.3, as a way to improve dependency management. It explains how richer metadata can represent variants such as platform-specific binaries, source packages, and alternative API implementations, allowing consumers and build tools to express and resolve more precise requirements.

## Source excerpt

Gradle Module Metadata reaches 1.0 in Gradle 5.3 and here we explain why you should be as excited as we are! Gradle Module Metadata was created to solve many of the problems that have plagued dependency management for years, in particular, but not exclusively, in the Java ecosystem. It is especially important because POM files (or Ivy files) are simply not rich enough to describe the reality of software nowadays where you might need to distinguish between binaries for different platforms or choose one particular implementation of an API when more than one is available. We will describe more examples later in this post. Some issues may have workarounds, but where those workarounds are hacky ones or even error prone. For example, did you realize that these are problematic: using classifiers for different Java versions, exclusions to avoid a particular logger binding, or adding first level dependencies just because you need to override a particular version? Gradle Module Metadata 1.0 is an answer to those problems and the first step towards better dependency management throughout our industry. What does it allow in practice? Have you ever cursed when you had both guava-jdk5 and guava-jdk8 on the classpath, and your application only worked because of lucky ordering of entries? Have you ever faced the problem of having different SLF4J bindings and only noticed at runtime? That's because these libraries have different variants that can't be described properly by existing metadata formats. How is a build tool even supposed to understand the difference between a jdk8 JAR, a sources one, or even an all one? Gradle Module Metadata is designed to explain the difference in such a way that consumers can express more precise requirements. For example, a consumer can specifically ask for something they can use with JDK 8. And in the case of SLF4J, the build tool will recognize that the Log4J binding is mutually exclusive with the java.util.logging one. The whole idea is to support