Open skiedrowski opened 1 year ago
This error usually indicates that jar is corrupted, i.e. something went wrong when downloading the jar from the repository.
This error usually indicates that jar is corrupted, i.e. something went wrong when downloading the jar from the repository.
Which jar? a vaadin jar, another dependency? a jar build for another part of the project? The stack trace does not provide a lot of information.
which jars are affected by the workaround "stopping the gradle daemon"?
Which jar? a vaadin jar, another dependency?
It is really hard to say. It can be just random. I recall that m2e plugin in Eclipse had a bug, that caused random broken jars back in time, this could be something similar.
Looks similar to vaadin/vaadin-gradle-plugin#116 and vaadin/vaadin-gradle-plugin#81 . It could also be that the dependency is not of type zip (i've seen projects pulling .dll/.so files as dependencies, causing this issue to appear), however the irregular nature of this ticket doesn't support this.
It would help if Flow would log the name of the problematic .jar file; filed https://github.com/vaadin/flow/issues/15457 It would be also worthwhile to investigate whether Vaadin 23 closes the files properly; see https://github.com/vaadin/vaadin-gradle-plugin/issues/81#issuecomment-690909269 for more information.
Meanwhile, can you please try the workaround from vaadin/vaadin-gradle-plugin#81 and try running gradle with --no-daemon
whether that would improve things?
Also, I can see that the ticket targets Vaadin 23.x. This repository is only for tickets targeting Vaadin 14.x. Could you please open a ticket at https://github.com/vaadin/flow/issues ?
Anyway, this ticket targets Vaadin 23.x. @TatuLund can you transfer this ticket to https://github.com/vaadin/flow/issues ?
Whoa, I can do it myself :+1: :-D
There are no native dependencies that I am aware of. TestBench/Selenium is using chromedriver but not as a build dependency, I guess. As you've said, the irregular behaviour does not support this theory.
Using --no-daemon
works. But this is just another workaround similar to stopping the daemon which slows down development.
How could I check whether the files are closed properly? #81 is closed.
Thanks for moving to the right repo. 👍
If you have Maven you can run
mvn com.github.s4u.plugins:pgpverify-maven-plugin:check
to verify all the dependencies used in the project. Not sure if there is something similar for Gradle. It does sound like you have a bad jar file somewhere
To contribute to the original report,
I experience the same general error. The stack trace looks the same, however I get a different message from gradle:
Visiting class [classname] failed with ZipFile invalid LOC header (bad signature).
This might be a broken class in the project.
where [classname] is a classname of a class from our own source code.
Stopping the daemon helps me as well.
Desktop: MacOS 13.2, arm, openjdk 19.0.2, gradle 7.6, Vaadin 23.3.4
Thanks for chiming in!
In the meantime we've figured the following
Where does the problem originate from? The gradle-vaadin-plugin? Kotlin compiler? Gradle daemon? ...?
Run into same problem, Java Project (no kotlin) and the problematic class was a generated one using OpenAPI Generator Plugin
Task :my-project:vaadinBuildFrontend FAILED Visiting class ch.my.project.client.some.generated.MyClass failed with ZipFile invalid LOC header (bad signature). This might be a broken class in the project.
OS: macOS 14.6 JDK version: 21 (temurin) Gradle version: 8.8 Vaadin Plugin version: 24.4.4
Workaround: kill gradle daemon
Hello everybody
I run into the same problem multiple times. The problem seems to happen when I run ./gradlew net.tangly.erp.ui:installDist -Pvaadin.productionMode
on the command line and IntelliJ IDEA is open with the same project decide to also start Gradle without the production mode set in the background.
The affected class is one in project e.g. Visiting class net.tangly.erp.products.ui.ProductsView failed with ZipFile invalid LOC header (bad signature).
It seems to be always a class containing Vaadin code.
(My repository is under https://github.com/tangly-team/tangly-os
).
The workaround of ./gradlew --stop
works fine. Thanks for the tip @mpneyer 👍
The workaround is fast and allows us to work daily.
The problem could be in vaadinBuildFrontend
running in parallel.
OS: macOS Sonoma 14.6.1 JDK Version: Oracle JDK 21 "22.0.2" 2024-07-16 Java(TM) SE Runtime Environment (build 22.0.2+9-70) Gradle version: 8.10 (use the Groovy DSL in project) Vaadin plugin version: 24.4.11
Desktop (please complete the following information):
Describe the bug Running
./gradlew vaadinBuildFrontend
sometimes fails withZipException: ZipFile invalid LOC header (bad signature)
(Stacktrace1.txt).There are days without the bug, there are others where every
vaadinBuildFrontend
causes the error.Identified preconditions: The Bug only surfaces
Workaround Stop the daemon using
./gradlew --stop
and run the task again.To Reproduce Reproduction is not possible... it seems to be somewhat dependent on the changes made to the sources.
Expected behavior successful frontend build
Additional context Add any other context about the problem here.