ZipException with Gradle 8.1.1


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'.
> 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.

I also included the stacktrace. (4.4 KB)

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.

As a work-around you could maybe disable the jar task that produces the empty jar and delete it from the filesystem.

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.

I think I’ve pinpointed the problem. In my MCVE, as long as I use mavenCentral for plugins, all is fine.

pluginManagement {
    repositories {

But company requires us to use self-hosted Nexus repository. So when I use our config:

pluginManagement {
    repositories {
        maven {
            name = "Nexus"
            url = uri("")
            isAllowInsecureProtocol = true // self-signed certificates
            metadataSources {

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 :smiley:

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 :slight_smile:

I found the file:

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.

Thanks again for helping Vampire :slight_smile:

1 Like

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. :slight_smile:

1 Like

GitHub issue: Gradle throws ZipException: "zip file is empty", when downloading from Nexus · Issue #26542 · gradle/gradle · GitHub

1 Like

Hi, I am having the exact same issue. How did you debug the gradle build to find the empty file?

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.