Is anyone else suddenly experiencing failures like...

# gradle

[mikehearn]

Is anyone else suddenly experiencing failures like Unable to find a variant of org.jetbrains.kotlin:kotlin-test:1.6.10 ? This just started now so I'm wondering if someone accidentally yanked an artifact from some repository. Not sure what the best channel to ask about this is.

[tapchicoma]

Could you provide error stacktrace?

[mikehearn]

> Could not resolve all files for configuration ':hydraulic.conveyor.tools.pom2json:testRuntimeClasspath'.
   > Could not resolve org.jetbrains.kotlin:kotlin-test:1.6.10.
     Required by:
         project :hydraulic.conveyor.tools.pom2json
      > Unable to find a variant of org.jetbrains.kotlin:kotlin-test:1.6.10 providing the requested capability org.jetbrains.kotlin:kotlin-test-framework-junit5:
           - Variant compile provides org.jetbrains.kotlin:kotlin-test:1.6.10
           - Variant runtime provides org.jetbrains.kotlin:kotlin-test:1.6.10
           - Variant platform-compile provides org.jetbrains.kotlin:kotlin-test-derived-platform:1.6.10
           - Variant platform-runtime provides org.jetbrains.kotlin:kotlin-test-derived-platform:1.6.10
           - Variant enforced-platform-compile provides org.jetbrains.kotlin:kotlin-test-derived-enforced-platform:1.6.10
           - Variant enforced-platform-runtime provides org.jetbrains.kotlin:kotlin-test-derived-enforced-platform:1.6.10

(there is no stack trace, I can use the --stacktrace flag if you want)

[mikehearn]

I haven't changed anything related to Kotlin or testing lately. So that's why I'm wondering if something changed server side.

[tapchicoma]

Sounds for me like variant selection problem rather then dependency resolution.

And I was going to say that something in your project was recently changed that causes it 🤷‍♂️

[mikehearn]

I haven't even changed the build system at all in the past week or so.

[mbonnin]

Make sure you resolve from mavenCentral. Artifacts are immutable there. I'd be surprised if there is any change. That'd be pretty bad from a supply chain security perspective

[mikehearn]

Looking at the module file on Maven Central, it seems it advertises capabilities with slightly different names. "kotlin-test-framework-impl" and "kotlin-test-junit5" but not kotlin-test-framework-junit5 indeed.

[mikehearn]

Oh no, sorry, that is for the kotlin-test-junit5 artifact, the kotlin-test artifact does indeed advertise with these capabilities. So what on earth ...

[Vampire]

Maybe there was a short outage or problem when you tried to resolve and it remembers that there was no such variant.
Try whether running with --refresh-dependencies fixes is.

[mikehearn]

I figured it out. In the repositories block, mavenLocal() had been placed above mavenCentral(). Didn't matter until today - presumably recently I opened a project that resolved kotlin-test into the local repository, at which point Gradle started finding the artifacts but not the gradle .module file. It was confusing because the error message does name some variants that the artifact exports so it took a while to think of this, as there's no useful debug logging that showed where it was trying to resolve from. Presumably, the variants it names are synthetic.

[Vampire]

You should actually never use mavenLocal() if possible.
And if you really need to, then you should at least use a repository content filter to only take things from there you know are good.
Maven local repository is broken by design.
It is not a pure repository, it is a mixture of repository and cache for Maven.
So as soon as a Maven project requested some file it is cached there, and then Gradle sees a broken state like you observed.

[Paul Woitaschek]

Absolutely this ☝️
We use exclusiveContent for everything but mavenCentral and google

[gildor]

We also use exclusiveContent for Google, fortunately it's easy to filter dependencies by group

[ilya.gorbunov]

@mikehearn @Vampire That's an interesting observation!
We had several reports like that (KT-45113, KT-50933), but it was always hard to reproduce them. Probably because the important part of reproducer, namely the state of maven local repository, was missing.

[Vampire]

Not so much an observation,
more another broken-by-design behaviour of Maven,
that is even documented in the Gradle documentation: https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local
🙂

[Vampire]

Whether the issues you mentioned have to do with this is unclear, as none of them mentions usage of mavenLocal()

[ilya.gorbunov]

I've rechecked the first one, and it indeed had mavenLocal repository declared above the repo from which the artifacts should have been resolved.

[Vampire]

Oh, ok, just looked at the code in the issue directly