Vladimir Sitnikov created MNG-7853:
--------------------------------------
Summary: Support Gradle Module Metadata
Key: MNG-7853
URL: https://issues.apache.org/jira/browse/MNG-7853
Project: Maven
Issue Type: Improvement
Components: Artifacts and Repositories, Dependencies, POM
Reporter: Vladimir Sitnikov
Currently, Maven lacks ability to describe and consume metadata for the
artifacts.
I suggest Maven should use Gradle Module Metadata format for both publication
and consumption.
Note: Gradle Module Metadata does not require Gradle, and it is a generic
format describing artifacts and attributes.
---
For instance, if somebody publishes "artifact with classifier", then Maven
can't express what stands behind the artifact, and there's no way to add a
dependency without mentioning the classifier explicitly.
There are cases when hard-coding artifact names is not workable:
* jars targeted for different JDK versions: -jre8.jar
* jars targeted for different Operating Systems: -linux, -windows, -...
* test jars: -tests.jar
All of the above have no metadata, so the ones who consume the jars can't just
ask "I need a Java 11 compatible artifact for macOS ARM". With Maven the only
possibility is to hard-code the classifier name, and the classifiers are
different across projects.
Gradle Module Metadata enables publishers to describe the set of published
artifacts, so it is easier to consume.
For instance, Guava uses versions like 28.1-android, 28.0-jre, and
26.0-android. It is a workaround to overcome the lack of metadata handling in
Maven dependency resolution.
It would be way better for the end users to declare "guava version they need
like 28.1", and "target platform they need like java 11". Then Maven should
resolve all the dependencies according to the requested attributes, so Maven
could resolve the appropriate classifiers for the dependencies. Ideally, the
use of explicit classifiers in dependency declaration should be deprecated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
