This message was deleted.
# community-support
s
This message was deleted.
r
Copy code
Caused by: java.util.zip.ZipException: zip END header not found
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository$openJarFile$1.invoke(ClassBytesRepository.kt:137)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository$openJarFile$1.invoke(ClassBytesRepository.kt:137)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository.openJarFile$lambda$3(ClassBytesRepository.kt:137)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository.openJarFile(ClassBytesRepository.kt:137)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository.access$openJarFile(ClassBytesRepository.kt:40)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository$jarClassBytesIndexFor$1.invoke(ClassBytesRepository.kt:116)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository$jarClassBytesIndexFor$1.invoke(ClassBytesRepository.kt:115)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository$classBytesSupplierForFilePath$1.invoke(ClassBytesRepository.kt:76)
	at org.gradle.kotlin.dsl.internal.sharedruntime.support.ClassBytesRepository$classBytesSupplierForFilePath$1.invoke(ClassBytesRepository.kt:76)
The stacktrace doesn’t give enough info, at least that I can recognize where the issue could be coming from
v
If it happens again, you could probably set a breakpoint to the exception being thrown and then go up in the call-stack to find which file causes it to then be able to have a look at its contents manually.
r
Huh interesting let me try that I’ve just added the breakpoint, do I need to run --debug to attach the debugger or by clicking sync it should already show up in the call-stack?
v
--debug
just increases the log level. If it is only happening during sync, you probably need to enable debugging using a
org.gradle.debug
Gradle property in
gradle.properties
. If it is also happening during normal build execution you could simply use the "Debug" run from IntelliJ, just make sure you did not disable Gradle Build Script debugging in the run configuration.
e
if it's from a normal artifact, I think Gradle will include it the path in the exception… have any other context from the stack trace?
r
Hey guys, thanks both, I was able to debug what file/dir is missing during sync time. For some reason the
/.gradle/cache/modules-2/files-2.1/foo-group/foo-artifact/foo-cache-key/foo-artifact.jar
is missing a cache key. It seems to happen with a custom gradle plugin I have applied, not sure why. Maybe the gradle plugin is compiled in 7.5 version and the project using it is 8.2.2? Or maybe the JDK? Not sure what could be the issue, but I already know it’s something I implemented on my own.
👌 1
I know the issue started showing up once the main project using the plugins bumped Gradle from 7.X to 8.+ That’s why I was thinking that maybe Gradle version could be involved.
Once again thank you @Vampire, the debug tool was really useful.
👌 1