This message was deleted.

Not really. What is there is pretty minimal: https://docs.gradle.org/current/userguide/variant_attributes.html#sec:abm_disambiguation_rules Disambiguation rules do not really interact with each other. What happens is that once Gradle has filtered out incompatible variants, it looks at the remaining ones and filters them through disambiguation rules independently, looking for an intersection. In your case, the api vs. runtime rule will prefer

apiElements

. But the packaging rule (fat jar vs. external deps) will prefer

unshadedRuntimeElements

. And so there is no intersection between the rules. And this results in a failure. However changes are being made around that area, and attributes will have a hierarchy. This should allow such a case to properly resolve, because usage will be looked at first over bundling. @Sterling Can you share more on this? (and you left a project name in there Chris 😉 )

That sounds great and makes sense. I’ve got around this for now by creating a custom

LibraryElements

attribute value for the

unshadedRuntimeElements

configuration and then defining a new

AttributeCompatibilityRule

to define how this value interacts with the existing values.