AmbiguousConfigurationSelectionException with .module dependency

[trevjonez]

Expected Behavior

Projects that produce the a .module metadata file should be able to produce a backwards compatible pom file without causing ambiguity issues in the variant aware downstreams.

Current Behavior

The consuming project gets stuck trying disambiguate between identical variant entries in the .module directory. The error message is also poor in that it shows the following:

Cannot choose between the following variants of com.trevjonez:and-lib:0.1.0: releaseApi
All of them match the consumer attributes: Variant 'releaseApi':

In this case there is two instances of releaseApi listed in the variants differing only by the download location, even though the artifact hash's are identical.

Context

I am building a plugin to add variant aware and relatively pain free artifact publishing via the maven-publish gradle plugin. My downstream consumer only works when I omit a base level default configuration, this causes my base level pom file to be generated without dependencies listed.

I could really use some better context on expected behavior of these types of publications. I think I may have thought of a solution as I type this up right now but it might be just a workaround not a solution.

Steps to Reproduce (for bugs)

• clone: https://github.com/trevjonez/android-components-plugin
• checkout: 88f6f6cdfaad36434ba3c43137d5f983c2c6bfa6
• invoke: ./gradlew test
• inspect: result of com.trevjonez.AndroidComponentsPluginTest.'app can consume lib'

Your Environment

• Test subject project Build scan URL: https://scans.gradle.com/s/ahzivfq7qwkpo/failure?openFailures=WzBd&openStackTraces=WzIse31d#top=0
• Top level project build scan URL: https://gradle.com/s/5osx77ljv2cvi
• .module file currently generated: https://gist.github.com/trevjonez/2a8646a81f9beea158a1db828939906a

[trevjonez]

I found a solution (workaround?) that involved creating a legacy variant usage context to attach to my root software component instance that allows a pom to be generated so that it will redirect to the default variant.

I added two more files to the OP .module gist that show the output changes by using the legacy usage. guidance on the right way to handle this situation would be great.

[ZacSweers]

I think this issue is actually pretty severe now that more MPP projects are coming into the fold. This breaks kapt entirely for Kotlin projects right now if any MPP dependencies are on the kapt configuration (transitive or direct), and also breaks some other plugins when resolving configurations.

Kapt issue filed here: https://youtrack.jetbrains.com/issue/KT-31641. Repro steps here https://youtrack.jetbrains.com/issue/KT-33206

Another gradle plugin example: ben-manes/gradle-versions-plugin#334

[ljacomet]

If I understand correctly the original question:

• you want to publish a single Android lib with debug and release flavors, mixed with api and runtime variants,
• for that, you will produce different Maven GAVs but all grouped under a single aggregated GAV so that, for Gradle, resolution can happen with .module metadata,
• but you still want the root Maven GAV to default to a variant and include the necessary information?

This clearly goes beyond the default .module <-> POM file mapping that Gradle does.

I think the easiest path is to actually modify the generated POM file in the root module so that it references what you pick as the default variant to resolve. So effectively aiming for your gist modification but without the legacy variant appearing the .module file.
Because you do all this in a plugin, from deciding what is published to how, it is the easiest and shortest path.

The only thing I could see Gradle doing here is fail in the case you try publishing 2 variants with the exact same attributes.

@ZacSweers I do not think the two issues are related. Here the problem is about creating the .module file, with duplicate variants causing a problem. While the kapt issue looks like a consumption one, where published files are valid, but the consuming configuration is not specific enough about what it needs when faced with MPP libs.

[ZacSweers]

As mentioned in my comment, this is not just a kapt issue. A regular gradle plugin that tries to call resolvedConfiguration on a configuration will receive the same error as mentioned in the original description ("Cannot choose between the following variants of..."). It's unclear what kapt or any other plugin reading configurations are supposed to do in this case. Happy to file a separate issue if you think it's different from this one, but I do believe this is a problem Gradle should solve. Otherwise it's just a land mine for unsuspecting plugins that try to read what looks like a perfectly normal public API.

[ljacomet]

I'll jump in the conversation on ben-manes/gradle-versions-plugin#334 to try to understand where the error is coming from exactly.

And I confirm my initial analysis: the issue here is a publication one while the other issues linked are consumption ones.

While it may require a fix at the publication site, it is much more likely that plugins will have to adapt to the upcoming features of variant aware dependency management, especially as leveraged by Kotlin MPP projects.

[ZacSweers]

@ljacomet just wanted to say thanks for the detailed explanations on both of the issues I linked above 👍. Hopefully they can get resolved soon with the added context, and apologies for the noise here

[ljacomet]

Closing as extra validation was added in #10769 and there is no further plan on solving the particular use case described here in core Gradle.