2.10.5 fails with "Cannot parse the provided input as org.jetbrains.intellij.platform.gradle.models.ProductInfo"

[BoD]

What happened?

Just updating to 2.10.5, I'm getting Cannot parse the provided input as org.jetbrains.intellij.platform.gradle.models.ProductInfo

Relevant log output or stack trace

Please see this Build Scan with all the logs and exception: https://ge.apollographql.com/s/tvlryxkrgsrco

Steps to reproduce

• Git clone https://github.com/apollographql/apollo-intellij-plugin
• Edit libs.versions.toml to put intellij-platform-plugin = "2.10.5"
• ./gradle buildPlugin

Gradle IntelliJ Plugin version

2.10.5

Gradle version

9.0.0

Operating System

macOS

Link to build, i.e. failing GitHub Action job

https://ge.apollographql.com/s/tvlryxkrgsrco

[hsz]

Thanks for reporting. This issue is related to the recent upgrade of xmlutil libraries, which bumped the kotlinx-serialization-json to 1.9.0.
This issue already appeared in #1885 almost a year ago, but I decided to revert everything back. Now, I'm sure we have to proceed with the upgrade, as it's already been too long, and due to security reasons, we need to update our dependencies.

However, I took a closer look at your project, and the

java.lang.AbstractMethodError: Receiver class org.jetbrains.intellij.platform.gradle.models.ProductInfo$$serializer does not define or inherit an implementation of the resolved method 'abstract kotlinx.serialization.KSerializer[] typeParametersSerializers()' of interface kotlinx.serialization.internal.GeneratedSerializer.

exception happens because Gradle tries to execute the code compiled with newer kotlinx-serialization-json in version 1.9.0 using the 1.6.2.
The problem is, this happens not in the compilation phase, but a bit earlier — when resolving dependencies by Gradle.
This means, any tricks related to dependencies or configurations constrants and resolution strategy won't work.

The org.jetbrains.kotlinx.kotlinx-serialization-json:1.6.2 dependency comes as a transitive one from gratatouille-wiring-runtime, which is used by the apollo-gradle-plugin:

https://github.com/GradleUp/gratatouille/blob/fecbe824c27b988edff96a01db40a096a0053603/gradle/libs.versions.toml#L20
cc @martinbonnin

A workaround that makes build work is to enforce org.jetbrains.kotlinx.kotlinx-serialization-json:1.9.0 in Gradle buildscript, in the root build.gradle.kts:

buildscript {
  dependencies {
    classpath("org.jetbrains.kotlinx:kotlinx-serialization-json:1.9.0")
  }
}

[BoD]

Thanks for the detailed analysis 🙏 I confirm that the workaround works.

[Nek-12]

Unfortunately the provided workaround doesn't work for us. Adding the line changes absolutely nothing. Any other workarounds?

[hsz]

@Nek-12 The reason of the issue is still valid — you're providing an old version of the library to the classpath. Analyze your project's dependencies and find wich one brings an outdated library.

Edit: I see you added my code to the debugger/ideplugin/build.gradle.kts‎ file, while I clearly explained this has to be added to the root one.

[Nek-12]

@hsz I already tried adding to the root - that didn't change anything. I figured, since we only apply the ide plugin in the ideplugin subproject, adding kotlin serialization workaround should also be there, but the end result is the same.

If i'm overriding the version with the newer one, how can it be possible that an old version is still provided?

[martinbonnin]

@Nek-12 you just bumped into the Gradle classloader hell. It's a long story, the tldr; is that each module has a separate classpath but there's also a "priority" in the classpath where the settings classloader has precedence over the root project classloader, which has precedence over each module classloader.

I recommend you load all your plugin in either your root project (or even better, settings) classpath so that there is central classpath management.

[Nek-12]

Ok, thank you @martinbonnin, I figured it out with the help of the article. Our project uses buildSrc, which is more classloady classloader than the root classloader which is the parent classloader for the ide plugin project classloader, so i had to override by adding an implementation block in the buildSrc dependencies. Unlike @hsz's advice, that helped solve the issue.

[martinbonnin]

@Nek-12 Right. buildSrc is special... TBH the whole thing is very complex to debug because there are so many possible cases, it's almost impossible to list them all. Jakub isn't responsible for Gradle's classloader hell, we're all in the same classloader boat.

If you have a chance, please upvote gradle/gradle#1370 to signal that something needs to be done about this.

[hsz]

@Nek-12 the solution based on the buildscript {} block is valid when you don't have custom buildSrc or build-logic involved. Otherwise, you should add that explicit dependency there, as you figured out. I'm glad you managed it!