unable to discover latest version of google guava

[nagkumar]

Failed to determine the latest version for the following dependencies (use --info for details):
 - com.google.guava:guava
     33.0.0-jre

using the pluings

 id("com.github.ben-manes.versions") version ("0.51.0")
    id("se.patrikerdes.use-latest-versions") version ("0.2.18")

[ben-manes]

You’d need to look at the info log. Guava has bad metadata unfortunately, so unsure

[milux]

Second this issue, plus some more affected libs:

com.fasterxml.jackson.core:jackson-annotations:2.17.2
com.fasterxml.jackson.core:jackson-core:2.17.2
com.fasterxml.jackson.core:jackson-databind:2.17.2
com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:2.17.2
com.google.protobuf:com.google.protobuf.gradle.plugin
org.jetbrains.kotlinx:kotlinx-coroutines-reactive:1.8.1
org.jetbrains.kotlinx:kotlinx-coroutines-reactor:1.8.1

[milux]

Is there any config option to ignore corrupted metadata if type and version do match the requirements?

[ben-manes]

You could disable module metadata from the source repositories.

repositories {
    maven {
        url = uri("http://repo.mycompany.com/repo")
        metadataSources {
            mavenPom()
            artifact()
            ignoreGradleMetadataRedirection()
        }
    }
}

[milux]

You could disable module metadata from the source repositories.

Nice, that "fixed" it. Could there be any side-effects of this I should be aware of? 🙈

[ben-manes]

For server-side projects then I don't think module metadata is customized very often because so many other build tools are used. I believe its primarily used by gradle only environments like android and kotlin for their cross compilation needs (webasm/arm64, android variant/flavors). Those two platforms tend to be brittle and full of hacks that don't honor gradle's apis so I imagine the module metadata was an attempt at rehabilitation to give their teams a path to become good citizens.

[milux]

Well, turns out that this "fix" is breaking certain dependencies like io.ktor in Gradle. That's Kotlin stuff, so maybe related to what you said in your last post?
I'm not sufficiently deep into this matter for helpful debugging information here, but it's reproducible, so I have to let it go for now.

[ben-manes]

There might be ways to fix the module metadata, but I'm not very knowledgable there. It seems that upgrading the kotlin plugin to 2.0.20-Beta1 or later may fix some problems because added a broken configuration (https://youtrack.jetbrains.com/issue/KT-68447).

Otherwise as a quick hack, you could do something ugly just for this plugin task by replacing the repositories prior to evaluation. Assuming you only run this task by itself then it won't negatively impact the rest of your build

tasks.dependencyUpdates.doFirst {
    repositories {
        clear()
	maven { ... }
    }
}