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

Open
ljacomet opened this issue Dec 2, 2019 · 11 comments
Open

Adoption of Gradle Module Metadata in open source libraries #11528

ljacomet opened this issue Dec 2, 2019 · 11 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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

@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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

@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

This comment has been minimized.

Copy link
Member

@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

This comment has been minimized.

Copy link
Member

@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

This comment has been minimized.

Copy link
Member

@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

This comment has been minimized.

Copy link
Member

@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

This comment has been minimized.

@jjohannes

This comment has been minimized.

Copy link
Member

@jjohannes jjohannes commented Jan 31, 2020

@jjohannes

This comment has been minimized.

Copy link
Member

@jjohannes jjohannes commented Feb 5, 2020

@ljacomet ljacomet added the @jvm label Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.