Hi I have encountered an issue when upgrading to ...

# gradle

[hantsy]

Hi I have encountered an issue when upgrading to 1.8.20, the gradle build failed due to an error like this.

> Could not find org.jetbrains.kotlin:kotlin-scripting-jvm:1.8.20.
     Searched in the following locations:
       - file:/C:/Users/hantsy/.android/manual-offline-m2/gmaven_stable/org/jetbrains/kotlin/kotlin-scripting-jvm/1.8.20/kotlin-scripting-jvm-1.8.20.pom
       - <https://plugins.gradle.org/m2/org/jetbrains/kotlin/kotlin-scripting-jvm/1.8.20/kotlin-scripting-jvm-1.8.20.pom>
     Required by:
         project : > org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.8.20 > org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.20 > org.jetbrains.kotlin:kotlin-scripting-compiler-impl-embeddable:1.8.20

[ephemient]

https://kotlinlang.slack.com/archives/C09222272/p1680227198472899?thread_ts=1680185137.213299&cid=C09222272

[thanksforallthefish]

a lot of people (I don’t, but every team in my company does) use automatic dependency updates, which unfortunately are not smart enough to know that a released artifacts in maven is not supposed to be used because another component is missing.

I think as a company we solved the issue by configuring the tool we use to ignore kotlin upgrades, but to me that is a hack. it would be nice to have some additional metadata, like ready to use since it is not possible to release all components at once and it takes several days

[Vampire]

That metadata is the existence of the blog post. 😄

[Vampire]

The update would most probably also work.
As I said, those tools just do not care where a dependency is coming from.
It is requested from GPP which redirects to JC which forwards to MC but still returns 404.
But the majority of those tools ignores the fact where a dependency is coming from.

The gradle-versions-plugin by benmanes for example would correctly not find the new Kotlin version, as it would only search in the actually used repository for the new version.
Any tool that just looks in Maven Central or all somewhere used repositories or similar are just wrong with their statement that an update is available, because in the acutally used repository the update is not yet available.

[Vampire]

So that those tools suggest an upgrade which then fails with not-found dependency is more a bug or limitation of those tools that do not work cleanly. 🙂

[tapchicoma]

actual problem this time that JCenter for some reason didn't synced this particular pom file, while all other is ok 🤷‍♂️

[tapchicoma]

it even synced pom.asc

[Vampire]

I guess the POM was requested before by some people trying to update prematurely even before it was in Maven Central, seen it is not there and remembered that fact.
Now some other tool probably requested the other files and they are properly cached.
Or something along those lines.

[hfhbd]

I still get this issue sometimes. Does anybody know if the sync issue will be fixed automatically by JCenter, eg syncing each week? The workaround using mavenCentral works.

[tapchicoma]

should be fixed already

[hfhbd]

What do you mean by already? One hour ago my build failed.

[hfhbd]

https://scans.gradle.com/s/6pipcymju36tm/tests/:gradle-plugin:test/app.softwork.serviceloader.KspTesting/kotlinMpp?top-execution=1

[hfhbd]

Repo: https://github.com/hfhbd/serviceloader-gradle-plugin/pull/42

[Vampire]

But that's different.
You see in the error that it did not try to get it from JCenter, but from Maven Central.
My guess would be, that you use some caching proxy on your side that thinks it is still not available, or that it was a temporary hickup.

[tapchicoma]

For me curl -vvv <https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-scripting-jvm/1.8.20/kotlin-scripting-jvm-1.8.20.pom> returns pom file

[hfhbd]

Hm, yes, the file is on mavenCentral and uploaded. I also have the file in my cache locally, so I don't get these errors on my machine.
The build fails only on the CI (GitHub Actions), even with cleaned build caches.