Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adoption of Gradle Module Metadata in open source libraries #11528

Closed
ljacomet opened this issue Dec 2, 2019 · 16 comments
Closed

Adoption of Gradle Module Metadata in open source libraries #11528

ljacomet opened this issue Dec 2, 2019 · 16 comments

Comments

@ljacomet
Copy link
Member

@ljacomet ljacomet commented Dec 2, 2019

With Gradle 6.0 and the automatic publishing of Gradle Module Metadata, a number of open source libraries could benefit from the features supported by that metadata format.

Help library authors and the community in general by suggesting libraries that could benefit from features like alignment, capabilities and more.

Please add comments indicating which library either offers Gradle Module Metadata or could benefit from it, with a link to an issue requesting the support.

This issue description will also be edited to list frameworks and libraries publishing Gradle Module Metadata.

@vlsi
Copy link
Contributor

@vlsi vlsi commented Dec 3, 2019

It would be nice to hear the way to control and test metadata.

I've a case when Gradle tries to use the metadata for the module that is not published to Nexus.

"library": https://github.com/apache/jmeter

The build is using java-platform to consolidate "dependency constraints" in a single place, then individual projects use the platform dependency.

So far so good (it allows to declare versions in a single place, the versions can be adjusted via the command line, and it does not suffer from buildSrc-change-recompile-all-modules issue).

The generated poms use resolved versions, so they do not really refer to bom (and it is even an unsupported case ).
That is why bom is not yet published to Nexus.

However, if I publish metadata for other modules (e.g. for :src:jorphan which uses platform(project(":bom"))), then the published metadata for :src:jorphan would include :src:bom reference. Apparently that metadata reference is invalid (as :bom is never published), so any attempt to use the published jorphan project with Gradle would fail as Gradle would try to download bom's metadata which is missing.

That is basically the case I disable metadata publication for now :-/

Is it something you want to hear here?

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Dec 6, 2019

Hi @vlsi. Thanks for the feedback. We would love to see jmeter publish Gradle Module Metadata soon. If I understand your comment and the discussion on #9866 correctly, you are publishing resolved versions to properly support Maven consumers, which can not "automatically" import the BOM. Which is a common use case.
There is #10861 for adding a feature that removes the platform dependencies from publication (which we plan to address soon). However, I was wondering if you would consider publishing the BOM/platform, even if it is a "duplication" of versions. If you publish the dependency to the platform it can be advantageous (for Gradle 6 users) because you always will have all constraints in the graph, also for the dependencies one of your modules does not have. This can help to better align versions in case of conflicts if your library is combined with others. See also our recent blog post about the topic: https://blog.gradle.org/alignment-with-gradle-module-metadata

@vlsi
Copy link
Contributor

@vlsi vlsi commented Dec 6, 2019

@jjohannes , BOM generation for JMeter is blocked by #11299 which has PR #11317 which has zero comments from Gradle team :'(

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Dec 6, 2019

Sorry @vlsi. I didn't catch that this is blocking your directly. The issue is on our list of upcoming work (a lot of things are going on right now). Thank you very much for the PR. We forgot to comment but it is on our radar. I'll see that we address it very soon.

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Dec 20, 2019

Junit 5

JUnit 5 publishes GMM starting with 5.6.0 🎉
https://repo1.maven.org/maven2/org/junit/jupiter/junit-jupiter-api/5.6.0

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Dec 20, 2019

Guava

There is a PR at Guava for publishing GMM: google/guava#3683

This is an interesting case as it covers multiple use cases (see google/guava#3683 for details):

  • Multiple variants for different JDK versions
  • Compile-only API dependencies to avoid annotation processor libraries on runtime classpath
  • Use capabilities to detect conflicting implementations (e.g. com.google.guava:guava vs. com.google.guava:listenablefuture)
  • Publish Gradle Module Metadata with Maven

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Dec 20, 2019

Android & AndroidX Libraries

AndroidX will publish GMM soon.

Publishing with Gradle 6+ and AGP (Android Gradle Plugin) 3.6.0 / 4.0.0 (beta/alpha available now) supports publishing of GMM by default. That allows for advanced use cases when publishing Android libraries. For Android libraries, you now have now a component available for each buildType/flavor combination (e.g. debug and release by default). But there is also a all component you can use to publish everything and then let Gradle select which variant to use at consumption times (as if the library where a local project).

afterEvaluate {
    publishing {
        publications {
            aar(MavenPublication) {
                from components.all
            }
        }
    }
}

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Dec 20, 2019

Other widely used Libraries

For inspiration, here are some more sample of how GMM could look for some well-known libraries (Guice, FLF4J, Hibernate, ...)
https://github.com/jjohannes/what-if-gradle-metadata/tree/master/usecases

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Jan 31, 2020

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Jan 31, 2020

SLF4J

Related blog post: https://blog.gradle.org/addressing-logging-complexity-capabilities

Discussion about the dev.jacomet.logging-capabilities plugin and GMM on the SLF4J user mailing list: http://mailman.qos.ch/pipermail/slf4j-user/2020-January/001736.html

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Feb 5, 2020

Jackson

Related blog post: https://blog.gradle.org/alignment-with-gradle-module-metadata

Discussion on the Jackson user mailing list: https://groups.google.com/forum/#!topic/jackson-user/OTwpIl6chUY

@ljacomet ljacomet added the @jvm label Feb 17, 2020
@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Feb 24, 2020

@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Feb 24, 2020

@britter
Copy link
Member

@britter britter commented Feb 27, 2020

Bean Validators

Additional validator implementations for javax.validation

britter.github.io/bean-validators
britter/bean-validators
repo1.maven.org/maven2/com/github/britter/bean-validators/0.7.0

@stale
Copy link

@stale stale bot commented Feb 26, 2021

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

@stale stale bot added the stale label Feb 26, 2021
@jjohannes
Copy link
Contributor

@jjohannes jjohannes commented Feb 26, 2021

We will close this as an issue as there are no more planned actions on this right now.

Thanks everyone who reported on the adoption of GMM here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants