I have an unusual error or setup again. We use multi-project build and one or two modules have no sources files. Only test files (some example tests or benchmarks tests). Although I am not sure if this is related.
Finally I could update Gradle from 7.6 to 8.0.2 and all went well. But with 8.1.1 I receive this rather cryptic error:
* What went wrong:
A problem occurred configuring project ':module:benchmarks'.
> java.util.zip.ZipException: zip file is empty
Does anyone have an idea what the problem might be? I have no idea what zip or jar file is it trying to open or why.
From a cursory look at the stacktrace I’d say this is a bug in the Gradle support for Kotlin DSL. And especially as it breaks from 8.0 to 8.1.
You should report it, optimally with an MCVE as regression, then you might even get a 8.1.2 or 8.3.1 that fixes it.
Oh, okay. The workaround doesn’t work for me. But I will try a few more things and I am going to try and provide an MCVE.
Thanks for the suggestion. I really appreciate it.
Make sure the empty jar is really not in the file system.
If it is not, it was probably just a coincidence and does not have anything to do with you producing an empty jar.
In that case you should probably debug the build execution and check which jar file it tries to read when this exception happens.
That might also help in creating an MCVE.
Then the problem starts to occur. So it seems to me that it’s an issue on our side and not in Gradle.
Or maybe only a particular plugin is a problem. Which is sad because I am not any closer to the solution
But it looks like switching to mavenCentral doesn’t fix the issue in my original project. Hm, interesting…
Independently on what exactly triggers it - maybe your Nexus delivering an empty jar for something - I think it is a bug in Gradle worth reporting.
To find out where exactly the problem is, as I said, you probably need to set a breakpoint in the failing code path to find out which jar is tried to be read and then you can maybe have a look at that file.
Cool that I’ve watched a talk about debugging gradle buildscripts in IntelliJ a couple of days back
I found the file:
/home/user/.gradle/caches/modules-2/files-2.1/org.springframework.boot/org.springframework.boot.gradle.plugin/2.7.8/da39a3ee5e6b4b0d3255bfef95601890afd80709/org.springframework.boot.gradle.plugin-2.7.8.jar
After deleting the file and running “gradle help” again, the same 0 byte file was created in that location. So I looked to Nexus. The JAR file in our Nexus was already corrupted and was empty. So that is the culprit. Well, talking to other devs, they have appeared some other files with 0B filesize during past few weeks.
Our admin also found a warning in Nexus that we reached some blob quota and changed the settings. So I really hope that is the problem.
I can still report it, maybe some nicer error message would be nice. But with all this info I guess the problem was inside Nexus instance afterall.
Yes, that should be the problem.
But I still think this should be handled better in Gradle with a more meaningful error also telling which file is problematic.
Could always happen by transfer issues or issues like yours that this happens.
So I’d still recommend you report it and post the link here for reference.
If you use IntelliJ IDEA, just run the problematic Gradle task with “Debug”, not “Run”, and set breakpoints accordingly.
If you use a different IDE you could for example use -Dorg.gradle.debug=true and then attach the debugger to port 5005 as soon as the daemon is waiting for the debugger.