https://gradle.com/ logo
Join Slack
Powered by
<#CAHSN3LDN|> We are also facing this problem sinc...
# community-support
a
#CAHSN3LDN We are also facing this problem since yesterday in our existing project. We haven't made any changes to it. We have tried everything we could including removing the gradle cache. All the gradle commands result in the below. java.util.zip.ZipException: zip END header not found. Please see the build scan at https://scans.gradle.com/s/sf44kerxpyah4
v
Some file seems to be corrupted. I'd say add a breakpoint to the top-most frame of the bottom-most exception and find out which file is the problematic one. Maybe the corruption is not local but on some repository proxy you use, or similar.
https://github.com/expo/expo/issues/34613 and https://lraman.com.np/blogs/react-native-gradle-plugin-build-error/ blame R/N to somehow have caused this and suggest steps to resolve it. But from your Scan it does not seem like you use R//N. Except if you use it in another project and it still is the cause. 🤷‍♂️
a
Thanks for replying @Vampire. Our current repo project contains 6 Spring Boot projects and 1 project in React with Kotlin Js. We are not using React Native at all. Also, it is working fine for one of our teammates, but failing with the same error for the rest of us. Please guide us.🙏
a
If you cleaned build-cache but it's still failing then it could be, that your remote cache has corrupted entry. If that is the case you will have to remove entry from remote cache or just nuke remote cache. Maybe first try running with 
--rerun-tasks
if that fixes it locally. This is pretty often the most effective way to fix local caches.
v
They already tried to delete all caches and it reappears, that's why I also said above that it might be some problem with repository mirror having a corrupt jar or similar. But it seems many people have that problem since yesterday, also not only from the same team it seems looking at the last two links I posted.
j
alternatively you could try to test all the JARs that are present in your Gradle home (right after a build failure):
Copy code
find /...path-to-gradle-home... -name '*.jar' -exec sh -ec 'jar tf "$1" > /dev/null && printf . || printf "\nFAILED: %s" "$1"' sh \{\} \;
note that you have to use the slower 
jar
and not 
unzip
as the latter could complain on "false positives" (that are arguably broken ZIPs, but in a different way than your issue, and they happen to work as JARs).
a
#CAHSN3LDN Please see the output.
v
Oh, wait, I've seen before today that this file is the one failing, but didn't recognize.
That does not make too much sense, this JAR does not exist
The 
org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin
artifact is a plugin marker, it only consists of a POM pointing to the actual code artifact
There must not be a JAR for that.
What is the actual content of that file? And what is the content of the according pom?
a
j
looks like some server or proxy is not replying with an appropriate status code when the resource doesn't exist...
v
Yes, so, we are back to the "central resource is delivering corrupted file", while actually Gradle should not even request the jar, but I guess the pom is likewise broken
a
But this is working for 1 person in my team successfully.
v
Maybe they have some cached state that works, or they run with 
--offline
(intentionally or accidentally) and thus do not get the broken stuff from remote, ...
If you check, they probably do not have that file
j
at this point you should manually test if you can access your maven repositories URLs
if you are behind a corporate firewall or proxy its configuration could be broken
or if you use other repos than the defaults maybe they are unavailable at this time
v
Or maybe Telstra broke something with your internet connection
a
@Vampire Yes, he doesn't have that file. I did check that.
Copy code
repositories {
    maven {
        url = uri("nexus-url-here/repository/maven2-proxy/")
        isAllowInsecureProtocol = true
    }
    maven {
        url = uri("nexus-url-here/repository/maven2-spring-proxy/")
        isAllowInsecureProtocol = true
    }

    mavenCentral()
}
This is configured in all 6 of our gradle projects. I am able to manually browse both of these urls. However, the second one doesn't have any files. Can that cause this issue?
v
Not having any files shouldn't cause this. But as you have seen in the file content, it returns some HTML code instead of a jar file or a proper failure status code like 404.
Also, did you check the pom in your cache, what is its content? I still wonder the jar is requested at all
And what does requesting "nexus-url-here/repository/maven2-proxy/org/jetbrains/kotlin/jvm/org.jetbrains.kotlin.jvm.gradle.plugin/1.9.24/org.jetbrains.kotlin.jvm.gradle.plugin-1.9.24.pom" and "nexus-url-here/repository/maven2-proxy/org/jetbrains/kotlin/jvm/org.jetbrains.kotlin.jvm.gradle.plugin/1.9.24/org.jetbrains.kotlin.jvm.gradle.plugin-1.9.24.jar" give you? If those work properly from browser, maybe you need to use some proxy now that you didn't configure for Gradle.
a
I can't locate pom files for this plugin in cache.
j
could you try this:
Copy code
curl -s -D - https://...nexus-url-here.../repository/maven2-proxy/org/jetbrains/kotlin/jvm/org.jetbrains.kotlin.jvm.gradle.plugin/1.9.24/org.jetbrains.kotlin.jvm.gradle.plugin-1.9.24.pom -o /dev/null
and paste the output?
should contain:
Copy code
HTTP/1.1 200 OK
...
Content-Type: application/xml; charset=UTF-8
Content-Length: 673
...
a
image.png
Here is the pom on the url
Here are the contents of all the 3 directories under ~/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin.jvm/org.jetbrains.kotlin.jvm.gradle.plugin/1.9.24
v
That you have two poms there is also already strange
One is probably the correct pom, the other probably also such an iframe
Maybe try to run the build with 
--refresh-dependencies
to make sure Gradle does rerequest all the files, in case it was a temporary server-side problem that is resolved now
a
I have tried --refresh-dependencies several times since yesterday to reach the zip error at the end. Here are the contents of the pom files. One of them seems fine while the other one just contains dependencies.
I have been deleting gradle cache using 
rm -rf ~/.gradle
. Is there anything else I can do for a workaround. This is a showstopper for us.
v
Well, find out why you get those ill responses from your Nexus server. This has not much to do with Gradle, except maybe if you need to use a proxy but did not configure Gradle to use it as I said before.
If the server is misbehaving and returns wrong result to Gradle requests, there is not much Gradle can do except for complaining.
j
I'm seconding that, definitely not the right content for the POM at 
org/jetbrains/kotlin/jvm/org.jetbrains.kotlin.jvm.gradle.plugin/1.9.24/org.jetbrains.kotlin.jvm.gradle.plugin-1.9.24.pom
, that should be:
Copy code
<project xsi:schemaLocation="<http://maven.apache.org/POM/4.0.0> <http://maven.apache.org/xsd/maven-4.0.0.xsd>" xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>" xmlns="<http://maven.apache.org/POM/4.0.0>">
      <modelVersion>4.0.0</modelVersion>
      <groupId>org.jetbrains.kotlin.jvm</groupId>
      <artifactId>org.jetbrains.kotlin.jvm.gradle.plugin</artifactId>
      <version>1.9.24</version>
      <packaging>pom</packaging>
      <dependencies>
        <dependency>
          <groupId>org.jetbrains.kotlin</groupId>
          <artifactId>kotlin-gradle-plugin</artifactId>
          <version>1.9.24</version>
        </dependency>
      </dependencies>
    </project>
you can try for yourself with the gradle plugin portal:
Copy code
curl -s -D - <https://plugins.gradle.org/m2/org/jetbrains/>...
mmh rereading that your proxy just adds metadata so that's not much of an issue actually, but then try the same 
curl
with 
.jar
instead of 
.pom
, it should not be a 
200
(or other 
2xx
) status code
the 
.pom
with additional metadata is the one served by Maven Central actually
👆 1
v
Nah, the shown POM content is fine. It is the POM as delivered from Maven Central, not the one delivered from Gradle Plugin Portal, but that is fine, even though JetBrains should consider cleaning that up if possible so that the same POM is published to boht.
a
Now I have changed all the projects' configuration to point directly to Maven. Gradle Reload - same issue.
Copy code
repositories {
    // Remote storage: <https://repo1.maven.org/maven2/>
    maven {
        url = uri("<https://repo1.maven.org/maven2/>")
        isAllowInsecureProtocol = true
    }
    // Remote storage: <https://repo.spring.io/milestone>
    maven {
        url = uri("<https://repo.spring.io/milestone>")
        isAllowInsecureProtocol = true
    }
    // maven { url = uri("<https://repo.spring.io/milestone>") }

    mavenCentral()
    // google()
}
v
Did you run with 
--refresh-dependencies
?
If so and still the error happens with these external repositories, again my assumption that you need to use a proxy to access the outworld but did not configure it for Gradle usage.
a
Trying with 
--refresh-dependencies
now. And we are using Nexus as a proxy. I just disabled it.
Same error.
v
I meant a network proxy
If you can request the POM successfully from your browser, check your browser and / or OS settings whether some proxy is configured.
a
No proxies
v
Well, there is not much we can help you with here. Gradle is not getting a correct answer and you have to find out why, but that is outside of the control of Gradle, and I can hardly debug your network.
n
(following as we’re having the same problem on the React Native ecosystem. That’s more widespread and seems to be specific to users depending on Kotlin 1.9.24. Other versions of Kotlin are not affected: https://github.com/facebook/react-native/issues/49115)
v
Ah, you found the thread 🙂 As I said depending on another version probably does not fix it but just mitigates the problem as not a bad cached version of ill server responses is used or something like that. 🙂
n
Yeah I agree. I’m trying to understand what is the problem here, as it’s a plethora of users reporting this and it’s unlikely they’re all behind a nexus/proxy
v
Maybe it was an issue even more central, GPP or MC delivering bad results. Once it is in the Gradle cache, it will not be rerequested unless you use 
--refresh-dependencies
, and those using some caching proxy or mirror may also have a poisened cache / proxy there so that 
--refresh-dependencies
would also not help. 🤷‍♂️ Hard to tell from outside where exactly the bad content is coming from if it still is coming, as some said (including in this thread here) that they deleted the Gradle caches and it still happens.
Except for one colleague where it is working as expected, where my suspicion is, that he might run with 
--offline
or similar.
n
mmm could this be related to some issues with the Maven Central CDN? I have the suspect most of the users are based in india or in countries with some geo restrictions. Still it’s surprising this happens only for Kotlin 1.9.24
v
Again, I don't think this is "happens only for Kotlin 1.9.24". I think 1.9.24 is maybe broken in some poisened cache or mirror and using 1.9.25 just works because it is not poisened. So most probably this was just a temporary problem of which we just still see the waves. 🤷‍♂️
a
Thanks a ton @Nicola Corti. Changing the Kotlin version to 1.9.25 has worked.
đź‘Ś 1
đź‘Ť 1
That's why we opened this at the Kotlin Slack as well. How can we report it to the Kotlin team when their repo doesn't have a way to open issues.
v
The issues are at youtrack.jetbrains.com project 
KT
. But again, the published files of the Kotlin plugin are fine. It is an infrastructure problem somewhere where a server gave ill responses, not something the Kotlin team could influence.
n
It seems to be geo-related. The ministry of electronics in India blocked the URL of the pom file: https://github.com/facebook/react-native/pull/49135#issuecomment-2634254709
🤦 1
v
Oh, my, ... If they at least would have used a proper HTTP status response and not just deliver an HTML page successfully 🙄
j
some f"ine" firewalling indeed ... but then gradle is lacking some mitigations here: • should not even try to download a 
.jar
as the 
.pom
says there is none • the build could (and should IMO) use gradle's dependency verification (checking signatures) to reject the 
.jar
the latter one alone would still have failed the build, but at least with some useful reporting instead of having to test all .jars in cache
v
• should not even try to download a 
.jar
as the 
.pom
says there is none
I suspect that the pom has a similar content, so was not able to be parsed as pom and thus the jar was searched. This behavior is indeed configurable by a Gradle build by configuring the metadata sources of a repository.
j
Mmh I suspected that as well but then their 
curl
on the 
.pom
did return valid data and they tried with 
--refresh-dependencies
. I suspect gradle to run the queries in parallel and not use the 
.pom
data to discard the 
.jar
data even if it got a valid status code, but that would require some testing to confirm the behaviour. Anyway we lack the results of the 
curl
on the 
.jar
on their proxy, and overall it still looks very much like proxy cache poisoning.
đź‘Ť 1
10 Views
Open in Slack
PreviousNext
Powered by