Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/jjohannes/gradle-module-metadata-maven-plugin
A Maven plugin to publish Gradle Module Metadata
https://github.com/jjohannes/gradle-module-metadata-maven-plugin
gradle maven-plugin
Last synced: 3 months ago
JSON representation
A Maven plugin to publish Gradle Module Metadata
- Host: GitHub
- URL: https://github.com/jjohannes/gradle-module-metadata-maven-plugin
- Owner: jjohannes
- License: apache-2.0
- Created: 2020-02-25T16:50:42.000Z (almost 5 years ago)
- Default Branch: main
- Last Pushed: 2024-01-08T09:27:12.000Z (about 1 year ago)
- Last Synced: 2024-01-08T10:55:32.392Z (about 1 year ago)
- Topics: gradle, maven-plugin
- Language: Java
- Homepage:
- Size: 167 KB
- Stars: 12
- Watchers: 2
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.MD
- License: LICENSE
Awesome Lists containing this project
README
# Maven plugin to publish Gradle Module Metadata
This Maven plugin is for JVM library developers that use Maven as build tool, but are also interested in supporting Gradle users of their library by leveraging some of the new dependency managment features introdued with Gradle 6.
This plugin allows you to publish [Gradle Module Metadata](https://github.com/gradle/gradle/blob/master/subprojects/docs/src/docs/design/gradle-module-metadata-latest-specification.md) for libraries built with Maven.
It automatically adds the same dependency information present in the POM to a Gradle Module Metadata file (`.module`) and adds that file as additional artifact to be _installed_ and _published_.
If Gradle Module Metadata is published, [Gradle 6+](https://gradle.org) will use that information in place of the POM.Because Gradle Module Metadata is a richer format, it allows you to add additional information about your library.
If published, Gradle 6+ can make use of that information during dependency resolution to detect and solve dependency conflicts that involve your library.
Currently, this plugin supports the following features that cannot be expressed in POM metadata:- [Platform Dependencies](https://blog.gradle.org/alignment-with-gradle-module-metadata)
- [Capabilities](https://blog.gradle.org/addressing-logging-complexity-capabilities)## Using the Plugin
Add this line to the top of you `pom.xml` right in the beginning of the `` tag:
```
```
Add the plugin to your build:
```
de.jjohannes
gradle-module-metadata-maven-plugin
0.2.0
gmm
...
...
...
...
...
```
Note: You may apply the plugin in a parent POM to publish Gradle Module Metadata for all modules using that parent.
## Adding platform dependencies
In Gradle terminology, a _platform_ is a [component to control transitive dependencies](https://docs.gradle.org/current/userguide/platforms.html).
A Maven BOM can be used as a platform by declaring a dependency to it.
Which means that, in contrast to Maven, another component can depend on a BOM instead of importing it.
The advantage is that such a _platform dependency_ can be published in Gradle Module Metadata.
This can, for example, be used to automatically align versions of related components as illustrated in this [blog post](https://blog.gradle.org/alignment-with-gradle-module-metadata).This plugin allows you to add platform dependencies _in addition_ to the dependencies defined in the POM.
You define a platform dependency inside the `` block in the plugin configuration.For example:
```
com.fasterxml.jackson
jackson-bom
2.10.2
```
If you add that to your POM, the `jackson-bom` will automatically be used by all Gradle 6+ builds depending on your library.
## Defining capabilities
A [capability](https://docs.gradle.org/current/userguide/dependency_capability_conflict.html) is defined by GAV coordinates just as a published component.
This can be used to express that two different components implement the same thing (i.e. the same _capability_) and can thus not be used together.
If Gradle 6+ detects multiple components with the same capability in a dependency graph, it fails and allows the user to define the resolution (i.e. select one of the conflicting implementations).
An example, which is described in detail in this [blog post](https://blog.gradle.org/addressing-logging-complexity-capabilities), is that `org.slf4j:slf4j-simple` and `ch.qos.logback:logback-classic` are both SLF4J bindings and only one can be used at runtime (so one should be chosen).Another use case is the relocation of a module to new coordinates.
Then the never versions can define the old GAV coordinates as capability to indicate that both implement the same thing.
(If a component does not define capabilities, like all components published only with POM metadata, they automatically have a single capability corresponding to the component's GAV coordinates.)
An example, from this [blog post](https://blog.gradle.org/guava), is `com.google.collections:google-collections` that was relocated to `com.google.guava:guava````
com.google.collections
google-collections
```
## Supporting more features
Gradle Module Metadata offers many more features.
To make use of them, you should consider to use [Gradle 6+](https://docs.gradle.org/current/userguide/getting_started.html) directly as build tool for your library.There might still be some other interesting things that could be done in Maven builds by extending this plugin.
In that case, please [file an issue](https://github.com/jjohannes/gradle-module-metadata-maven-plugin/issues) (or [open a pull request](https://github.com/jjohannes/gradle-module-metadata-maven-plugin/pulls)) that describes the use case.