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

Unexpected behavior with Gradle Module metadata #52

Open
Vampire opened this issue Dec 2, 2021 · 0 comments
Open

Unexpected behavior with Gradle Module metadata #52

Vampire opened this issue Dec 2, 2021 · 0 comments

Comments

@Vampire
Copy link

Vampire commented Dec 2, 2021

The readme states:

The following publishing plugins support the correct handling when generating the relevant metadata:

Maven Publishing
Ivy Publishing

This is not really correct.
It is correct only for the POM and ivy.xml files.
But nowadays those plugins also automatically publish the Gradle Module metadata file.
That file is not touched by this plugin and there the "optional" dependencies land as non-optional.
For example compare org.mnode.ical4j:ical4j:3.0.25 POM and ivy.xml files.
In the POM there are three optional dependencies, in the Gradle Module metadata file they are required dependencies.

Actually imho this plugin should not be used anymore at all, but instead Gradle feature variants used.
Those will end up as optional in the POM automatically and be proper feature variants in the Gradle Module metadata that you can then select explicitly in a consumer Gradle build, automatically getting the proper dependencies including version.

Currently a publisher just uses your plugin and trusts the promise that the metadata is handled properly, but Gradle consumers always get those optional dependencies while Maven users don't and the most downstream projects will also not recognize that they have a too large class path due to this.

If this plugin is applied and Gradle Module metadata is published too, maybe it should fail the build and recommend to use feature variants instead, or just deprecate the whole plugin and always recommend feature variants, if the Gradle version is new enough to support them.

You can find more information about feature variants for "optional" dependencies at:
https://blog.gradle.org/optional-dependencies
https://docs.gradle.org/current/userguide/feature_variants.html

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

No branches or pull requests

1 participant