vaadinBuildFrontend irregularly failing with ZipException: ZipFile invalid LOC header (bad signature)

[skiedrowski]

Desktop (please complete the following information):

• OS: macOS 12.x, macOS 13.x, Ubuntu 22.4, Windows 11
• JDK version: 11 (temurin + zulu tested)
• Gradle version: 7.5.1
• Vaadin Plugin version: 23.1.17

Describe the bug
Running ./gradlew vaadinBuildFrontend sometimes fails with ZipException: 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

• when there are changes made to the gradle project containing the Vaadin UI
• when the gradle daemon is used (from the 2nd run)
• ?

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.

[TatuLund]

This error usually indicates that jar is corrupted, i.e. something went wrong when downloading the jar from the repository.

[skiedrowski]

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.

[skiedrowski]

which jars are affected by the workaround "stopping the gradle daemon"?

[TatuLund]

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.

[mvysny]

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 #15457
It would be also worthwhile to investigate whether Vaadin 23 closes the files properly; see vaadin/vaadin-gradle-plugin#81 (comment) 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 ?

[mvysny]

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 👍 :-D

[skiedrowski]

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

[Artur-]

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

[contradictioned]

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

[skiedrowski]

Thanks for chiming in!

In the meantime we've figured the following

• The affected class is from our project (not from a dependency). So the mentioned ZipFile must have been created by gradle (?).
• There are two different classes causing the problem, which are both Kotlin classes (in a mixed Java/Kotlin setup).

Where does the problem originate from? The gradle-vaadin-plugin? Kotlin compiler? Gradle daemon? ...?