Hello Gradle people, I’m reaching out for assistan...
# community-support
m
Hello Gradle people, I’m reaching out for assistance regarding some issues we're encountering in our Kotlin multiproject setup after upgrading from Java 17 to Java 21. Our local builds, executed in a macOS environment, complete successfully without any issues, but the Github CI build fails with the following error:
Copy code
Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
class org.gradle.kotlin.dsl.PluginDependenciesSpecScope, unresolved supertypes: org.gradle.plugin.use.PluginDependenciesSpec
class org.gradle.accessors.dm.LibrariesForHumlaInPluginsBlock, unresolved supertypes: org.gradle.api.internal.catalog.AbstractExternalDependencyFactory
...
Our Project Structure: We have a Kotlin monorepo set up as a multiproject with separate projects for libraries and services. We are currently using Gradle 8.8. Dependencies and Plugins: Here are some key dependencies and plugins from our version catalog: • Kotlin: 2.0.20 • Ktor: 2.3.12 • Jackson: 2.17.2 • Exposed: 0.54.0 • Flyway: 10.18.1 • Apollo: 3.8.5 • Detekt: 1.23.7 Plugins: • Apollo: com.apollographql.apollo3 • Detekt: io.gitlab.arturbosch.detekt • Kotlin: org.jetbrains.kotlin.jvm The Issue Updating to Java 20 works fine but we get some randomly occurring problems running Gradle 8.8 with Java 21 on GitHub when building our libs. Interestingly, when debug logging is enabled, the build works as expected. Steps Taken • Verified that we’re using Gradle 8.8 consistently across local and CI environments. • Checked the Java version and confirmed that it is set to 21 in both local and CI setups. • The Gradle wrapper version is up-to-date (8.8). • No known incompatible plugins were found in our version catalog. Could anyone advise on what might be causing these issues with Java 21? Are there known incompatibilities with any of the plugins or dependencies we’re using? Thank you for your help!
v
Are you able to share a build
--scan
URL of the failing run, or at least a full
--stacktrace
?
m
Untitled
v
Hm, that seems very strange. From the top of my head I'd say maybe the Gradle distribution is broken. Delete it from
<GRADLE_USER_HOME>/wrapper/dists/...
and try again.
Oh, this is on GHA. Can you run the build locally? If so, there is probably something strange or broken on the runner agent. 🤷‍♂️
m
It works fine locally We've been experiencing this issue since Java 21 was released, so it's not a temporary issue with the runner
v
But still, if it is working locally, but not on the GHA runner, it must be something local to the GHA runner, doesn't it?
d
👋 I’m taking over this thread from my colleague Madeleine. Yes, it’s definitely something with the runner. The question is what can we do to find a solution for it? We’re not using any self-hosted or custom runners and we use
gradle/actions/setup-gradle@v4
to setup gradle (recommended gradle wrapper setting). We use the same setup when we build services (which works). If anyone has any pointers to what we could do to resolve this it would be much appreciated.
t
Are you using the same
libs/apple-notification-client/gradlew -p libs/apple-notification-client
way of invoking Gradle locally? or more something like
cd libs/apple-notification-client && ./gradlew …
? I don't think it should make a difference but who knows 🤷
d
Normally not but I’ve tried that as well just to make sure. And it also works locally…
v
If recommend using the tmate action to investigate. With that you can SSH into the runner and try to find out what is causing the problem