Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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.
Attachments
Issue Links
- relates to
-
MNG-5652 "supplies"/"provides"/"proffers" concept proposal
- Open