-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Live reload failing with Zip archives generated by code.quarkus.io due to time zone issues #4064
Comments
@emmanuelbernard you can share the link to the generated app. |
I confirm that doing the same app with
Work as expected so it's either a bug from the code.quarkus.io generator or Quarkus 0.22 or a combination of both. BTW I don't understand why code. generates ExampleResource while the mvn pluging generates HelloResource, |
@ia3andy No time, I'm trying to salvage my demos for CodeOne |
As @gsmet guessed my files have a modified date in the future which must be screwing up things |
So I'm on macOS and use the code.quarkus.io in SFO. if that helps on the date problem and use the macOS native archive opener |
FWIW, the date issue is reproducible on a plain Fedora 30 so I think it's a general issue. |
This issue has been reproduced and seems to be due to the zip creation in Code Quarkus. I filed an issue there: quarkusio/code.quarkus.io#152 Let's keep that issue open until we actually have a fix. |
It's now fixed on code.quarkus.io I think as @maxandersen suggested, maybe it would be better to check the (risky?) files dates at build/runtime? |
Is it really fixed in the macOS archiver case in the end? |
@emmanuelbernard no it still bug, I'll create a new fix with a fixed date in the past (probably build date UTC - 12h). As discusses with @dmlloyd and @stuartwdouglas, in parallel, a fix in the quarkus dev watch algo seems important too. They suggested using date offset from the file dates. |
Not date offset: rather, record the dates for each file and compare to see if they've changed (in any way). Don't do arithmetic of any kind on filesystem dates/timestamps or dates/timestamps returned by the JVM - such operations are inherently unreliable in the face of DST, NTP, human error, etc. Just see if it's different or not different than it was before. |
…e.quarkus.io due to time zone i this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if las recorded time and current modification time are different.
…e.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if last recorded time and current modification time are different.
…e.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if last recorded time and current modification time are different.
…e.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if last recorded time and current modification time are different.
…e.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if last recorded time and current modification time are different.
…e.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if last recorded time and current modification time are different.
…e.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio#4064 (comment) and just check if last recorded time and current modification time are different.
…de.quarkus.io due to time zone issue this fixes the issue by implementing a solution proposed by this comment quarkusio/quarkus#4064 (comment) and just check if last recorded time and current modification time are different.
on 0.22
code.quarkus.io
with resteasy,resteasy-jsonb,panache,postgresql,openapi,validatorExampleResource.java
butapplication.properties
I would love for this exact scenario to be tested in unit tests because it has broken numnerous times in the past.
The text was updated successfully, but these errors were encountered: