You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The readme states:
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
The text was updated successfully, but these errors were encountered: