Quarkus: Live reload failing with Zip archives generated by code.quarkus.io due to time zone issues

[emmanuelbernard]

on 0.22

1. Start new project with code.quarkus.io with resteasy,resteasy-jsonb,panache,postgresql,openapi,validator
2. go in live reload
3. add TodoResource

@Path("/api")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class TodoResource {
    @GET
    public List<Todo> getAll() {
        return Todo.listAll();
    }
}

1. add Todo

@Entity
public class Todo extends PanacheEntity {
    public String title;
}

1. refresh http://localhost:8080/api
2. see Hibernate not configured error
3. add in application.properties

# set DB
quarkus.datasource.url=jdbc:postgresql:quarkus-demo
quarkus.datasource.driver=org.postgresql.Driver
quarkus.datasource.username=quarkus-demo
quarkus.datasource.password=quarkus-demo

# Hibernate details
quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.hibernate-orm.log.sql=true

1. refresh http://localhost:8080/api
2. You still see the error where it should not and the logs show that the hot reload detects the wrong file change (I did not update ExampleResource.java but application.properties

2019-09-17 07:07:00,034 INFO  [io.qua.dev] (executor-thread-1) Changed source files detected, recompiling [/Users/emmanuel/Code/quarkus/demos/CodeOne/hibernate-app/src/main/java/io/quarkus/hibernate/ExampleResource.java]
2019-09-17 07:07:00,247 INFO  [io.qua.dep.QuarkusAugmentor] (executor-thread-1) Beginning quarkus augmentation

I would love for this exact scenario to be tested in unit tests because it has broken numnerous times in the past.

[ia3andy]

@emmanuelbernard you can share the link to the generated app.
I think a tiny url feature would be great 😅

[emmanuelbernard]

I confirm that doing the same app with

mvn io.quarkus:quarkus-maven-plugin:0.21.2:create
mvn quarkus:add-extension -Dextensions=jdbc-postgresql,hibernate-orm-panache,hibernate-validator,resteasy-jsonb,openapi

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,

[emmanuelbernard]

@ia3andy No time, I'm trying to salvage my demos for CodeOne

[emmanuelbernard]

As @gsmet guessed my files have a modified date in the future which must be screwing up things

[emmanuelbernard]

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

[gsmet]

FWIW, the date issue is reproducible on a plain Fedora 30 so I think it's a general issue.

[ia3andy]

This issue has been reproduced and seems to be due to the zip creation in Code Quarkus. I filed an issue there: https://github.com/quarkusio/code.quarkus.io/issues/152

Let's keep that issue open until we actually have a fix.

[ia3andy]

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?

[emmanuelbernard]

Is it really fixed in the macOS archiver case in the end?

[ia3andy]

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.

[dmlloyd]

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.