Can I use different attributes for resolving the transitive dependencies of a dependency vs the attributes used to resolve the dependency itself?

There is no way to apply a certain set of attributes to variant selection for the subgraph of dependencies that a given dependency pulls in transitively

I'm diving into https://github.com/adamko-dev/dokkatoo/issues/165 again

Looking at your reproducer in the mentioned issue, the problem is, that

jvmRuntimeElements

is missing the

Bundling

attribute. This is requested:

| org.gradle.category                |  library                   |
    | org.gradle.dependency.bundling     |  external                  |
    | org.gradle.libraryelements         |  jar                       |
    | org.gradle.usage                   |  java-runtime              |

javaRuntimeElements

provides

| org.gradle.category                | library                   |
    | org.gradle.dependency.bundling     |                           |
    | org.gradle.libraryelements         | jar                       |
    | org.gradle.usage                   | java-runtime              |

    | org.gradle.jvm.environment         | standard-jvm              |
    | org.jetbrains.kotlin.platform.type | jvm                       |

dokkatooHtmlPublicationPluginClasspathApiOnlyConsumable

provides

| org.gradle.category                | library                   |
    | org.gradle.dependency.bundling     | external                  |
    | org.gradle.libraryelements         | jar                       |
    | org.gradle.usage                   | java-runtime              |

    | org.gradle.jvm.environment         | standard-jvm              |
    | dev.adamko.dokkatoo.classpath      | dokka-publication-plugins |
    | dev.adamko.dokkatoo.format         | html                      |

So

dokkatooHtmlPublicationPluginClasspathApiOnlyConsumable

simply matches better than

jvmRuntimeElements

as it matches 4 of the 3 requested attributes while the latter only matches 3. So the first bug here is, that the

jvmRuntimeElements

configuration does not provide the JVM ecosystem

Bundling

attribute. If now that variant would also provide the

Bundling

attribute, both variants would provide the same matching attributes but have different extra attributes. You can emulate this by adding to the

annotations

build script

configurations.matching { it.name == "jvmRuntimeElements" }.configureEach {
    attributes {
        attribute(Bundling.BUNDLING_ATTRIBUTE, objects.named(Bundling.EXTERNAL))
    }
}

With that it will then fail to resolve the dependency as it cannot decide between those two configurations, becuase both have the extra attribute

org.gradle.jvm.environment

with value

standard-jvm

, but one has the additional extra attribute

org.jetbrains.kotlin.platform.type

while the other has the extra attributes

dev.adamko.dokkatoo.classpath

and

dev.adamko.dokkatoo.format

and Gradle does not know which would be better. I'd say the next bug is, that actually the

dokkatooHtmlPublicationPluginClasspathApiOnlyConsumable

does not have

org.jetbrains.kotlin.platform.type

with value

jvm

, so let's also add that by also in the

annotations

project doing

configurations.matching { it.name == "dokkatooHtmlPublicationPluginClasspathApiOnlyConsumable" }.configureEach {
    attributes {
        attribute(KotlinPlatformType.attribute, KotlinPlatformType.jvm)
    }
}

Now both configurations have the same matching attributes. Both have the same 2 extra attributes with the same value. One has no more extra attributes. The other has two more extra attributes unique to them. Now the attribute resolution algorithm described at https://docs.gradle.org/current/userguide/variant_aware_resolution.html#sec:abm-algorithm can properly resolve the intended configuration and the annotation is found as expected. So I'd say the bugs to fix are, that the

jvmRuntimeElements

configuration is missing the

Bundling

attribute, and that the

dokkatooHtmlPublicationPluginClasspathApiOnlyConsumable

configuration is missing the

KotlinPlatformType.attribute

attribute. Once these two are fixed, there is no hacky work-around with Dokka-own attributes and compatibility rules, or poison values necessary, as then the resolution just works as intended.

Thanks for the deep dive! I see you commented on the pull request, I'll follow up there for posterity!