Resolving Kotlin Multiplatform via Gradle Metadata (AndroidX)

[cpsauer]

Hi wonderful Bazelers,

It looks like some of Android's Jetpack libraries (androidx) are starting to switch over to to Kotlin Multiplatform, which involves publishing (nearly) empty jars to Maven and then relying on Gradle metadata to resolve the actual coordinates. This breaks builds upon updating the libraries, since naively pulling the next version will now pull down the now empty JARs. I figured I should report in as soon as I figured out what was breaking our build in case it would be useful to others.

The quick workaround is just to depend on the jvm variant of the coordinates. For example androidx.annotation:annotation -> androidx.annotation:annotation-jvm.

But it'd be nice to handle this automatically so that people can use the canonical version and aren't confused into the future. For this jvm-focused repo, probably that involves just seeing if there's a -jvm version of the coordinate and transparently aliasing to that.

Cheers, Chris

[shs96c]

This would be addressed by #807, since that delegates down to gradle's own resolver. Since that's not landed yet, the next place to address this is with the coursier project: https://github.com/coursier/coursier That's what we currently use as our resolver.

[cpsauer]

Oh, great! Thanks for the cross-ref and all your work on that, Simon! (And for Selenium, which has been super useful to me and to friends in the past!)

I assume that we anticipate #807 landing soon enough that we should just use the workaround for now, rather than in coursier?

Some questions about the PR with respect to this issue:

• Would Gradle need the Kotlin Multiplatform plugin to resolve these correctly? And if so, does that fit nicely into the PR?
• Would this make gradle the default resolver, replacing coursier? (I saw this part of the PR, designating gradle as the default over maven, but didn't quickly see whether the new resolver was to become the default.)

Thanks so much, Chris