Resolving MPP dependencies - Could not resolve all files for configuration ':protomodule:compileProtoPath' - Cannot choose between the following variants

[olamelin]

Given a simple multi module project as can be seen here https://github.com/olamelin/protobuf-gradle-plugin-issue the protomodule:extractIncludeProto fails with the following stack trace

Execution failed for task ':protomodule:extractIncludeProto'.
> Could not resolve all files for configuration ':protomodule:compileProtoPath'.
   > Could not resolve com.squareup.okio:okio:2.4.3.
     Required by:
         project :protomodule > project :okhttp > com.squareup.okhttp3:okhttp:4.4.0
      > Cannot choose between the following variants of com.squareup.okio:okio:2.4.3:
          - jvm-api
          - jvm-runtime
          - metadata-api
        All of them match the consumer attributes:
          - Variant 'jvm-api' capability com.squareup.okio:okio:2.4.3:
              - Unmatched attributes:
                  - Found org.gradle.status 'release' but wasn't required.
                  - Found org.gradle.usage 'java-api' but wasn't required.
                  - Found org.jetbrains.kotlin.platform.type 'jvm' but wasn't required.
              - Compatible attribute:
                  - Required org.gradle.libraryelements 'resources' and found compatible value 'jar'.
          - Variant 'jvm-runtime' capability com.squareup.okio:okio:2.4.3:
              - Unmatched attributes:
                  - Found org.gradle.status 'release' but wasn't required.
                  - Found org.gradle.usage 'java-runtime' but wasn't required.
                  - Found org.jetbrains.kotlin.platform.type 'jvm' but wasn't required.
              - Compatible attribute:
                  - Required org.gradle.libraryelements 'resources' and found compatible value 'jar'.
          - Variant 'metadata-api' capability com.squareup.okio:okio:2.4.3:
              - Unmatched attributes:
                  - Required org.gradle.libraryelements 'resources' but no value provided.
                  - Found org.gradle.status 'release' but wasn't required.
                  - Found org.gradle.usage 'kotlin-api' but wasn't required.
                  - Found org.jetbrains.kotlin.platform.type 'common' but wasn't required.

The issue happens when there is a dependency on a Kotlin MPP project as the com.squareup.okio:okio:2.4.3 is.
It looks to be the same that existed in Kapt but has been resolved in version 1.3.60 https://youtrack.jetbrains.com/issue/KT-31641

[voidzcy]

Related to change made in #366. https://youtrack.jetbrains.com/issue/KT-31641#focus=streamItem-27-3698024.0-0 sounds to be likely the cause of this issue.

The problem is a total absence of attributes on the resolved configuration coupled with the default disambiguation rules from the Kotlin plugins.
Kotlin plugins define their own org.gradle.usage disambiguation rule which picks java-runtime-jars when nothing is requested.
Unfortunately, there is another Kotlin added attribute, org.jetbrains.kotlin.platform.type, which also has a disambiguation rule. But that one prefers common when no value is requested.
This means that between java-runtime and common as disambiguated values, there is no matching variant.

[olamelin]

But based on ljacomet's comment here gradle/gradle#6389 (comment) is this not the same consumer issue that the kapt suffered from as well as the ben-manes/gradle-versions-plugin#334 issue?

[iainmcgin]

I was able to work around this issue by adding the following to my build.gradle.kts:

configurations.forEach {
    if (it.name.toLowerCase().contains("proto")) {
        it.attributes.attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage::class.java, "java-runtime"))
    }
}

This is adapted from this suggestion that was more specific to using Square's wire implementation of gRPC, but in searching around for solutions to this issue I'm seeing a lot of related variant selection ambiguity issues. Hopefully the snippet above will help figure out how to update this plugin.

[olamelin]

It worked like a charm

[gnarea]

FYI, someone from the Gradle team had a quick look at this issue in this plugin and here's his summary: gradle/gradle#12126 (comment)

[alastairpatrick]

I worked around this by depending on the older 0.8.10 version of protobuf-gradle-plugin.

0.8.14 error
0.8.13 error
0.8.12 error
0.8.11 error
0.8.10 works
0.8.9 works

[voidzcy]

From gradle/gradle#12126 (comment), the compileProtoPath configuration indeed has some problem.

the protobuf plugin doesn't set the right attributes on the compileProtoPath configuration to be able to resolve the right variant.

Now as for setting the attributes: an error you make is that the attributes must be set on the resolvable configurations. It doesn't make sense to set attributes on compileOnly or implementation because those are just used to declare dependencies. They are never resolved. When we talk about the "consumer", this is actually a dependency graph, resolved. So compileClasspath, runtimeClasspath, compileProtoPath, ...

The easiest fix is probably to let it inherit from compileClasspath instead of implementation + compileOnly (Update: this will not work, as attributes are not inherited). Another way is to directly extract included protos from compileClasspath with an ArtifactView that request resources, and we get rid of compileProtoPath.