Quarkus: Liquibase still detects multiple changelogs despite upgrade to 1.4.1

[AwesomeIbex]

Describe the bug
Copied from previous ticket #8400 :
During startup of quarkus dev mode, Liquibase tries to parse the configured (yaml) file containing the changeLog, this fails due to 2 such files being found in the classpath. This error does not occur in normal mode (running the runner jar).

Expected behavior
Liquibase only finds one changeLog file and parses it.

Actual behavior

File: Found 2 files that match db/changeLog.xml
        at io.quarkus.liquibase.runtime.LiquibaseRecorder.doStartActions(LiquibaseRecorder.java:82)
        at io.quarkus.deployment.steps.LiquibaseProcessor$configureRuntimeProperties31.deploy_0(LiquibaseProcessor$configureRuntimeProperties31.zig:98)
        at io.quarkus.deployment.steps.LiquibaseProcessor$configureRuntimeProperties31.deploy(LiquibaseProcessor$configureRuntimeProperties31.zig:36)
        at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:182)
        at io.quarkus.runtime.Application.start(Application.java:89)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:90)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:61)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:38)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:106)
        at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:99)
        at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: liquibase.exception.ChangeLogParseException: Error Reading Migration File: Found 2 files that match db/changeLog.xml
        at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:118)
        at liquibase.parser.core.xml.AbstractChangeLogParser.parse(AbstractChangeLogParser.java:15)
        at liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:217)
        at liquibase.Liquibase.validate(Liquibase.java:1559)
        at io.quarkus.liquibase.runtime.LiquibaseRecorder.validate(LiquibaseRecorder.java:124)
        at io.quarkus.liquibase.runtime.LiquibaseRecorder.doStartActions(LiquibaseRecorder.java:66)
        ... 15 more
Caused by: java.io.IOException: Found 2 files that match db/changeLog.xml
        at liquibase.util.StreamUtil.singleInputStream(StreamUtil.java:206)
        at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:71)
        ... 20 more

To Reproduce
Steps to reproduce the behavior:

1. clone https://github.com/gastaldi/liquibase-gradle-bug
2. change gradle.properties from 999-snapshot to 1.4.1.Final
3. ./gradlew quarkusDev

Configuration

# Add your application.properties here, if applicable.
#Gradle properties
#Mon Apr 06 13:51:25 GMT 2020
quarkusPluginVersion=1.4.1.Final
quarkusPlatformArtifactId=quarkus-bom
quarkusPlatformGroupId=io.quarkus
quarkusPlatformVersion=1.4.1.Final

#application.properties
quarkus.liquibase.change-log=db/changeLog.xml
quarkus.liquibase.migrate-at-start=true
quarkus.liquibase.validate-on-migrate=true
quarkus.datasource.db-kind=h2
quarkus.datasource.jdbc.url=jdbc:h2:mem:test
quarkus.datasource.jdbc.max-size=8
quarkus.datasource.jdbc.min-size=2

Screenshots
(If applicable, add screenshots to help explain your problem.)

Environment (please complete the following information):

• Output of uname -a or ver: Darwin kaluza.broadband 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64
• Output of java -version: openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment GraalVM CE 19.3.1 (build 11.0.6+9-jvmci-19.3-b07) OpenJDK 64-Bit Server VM GraalVM CE 19.3.1 (build 11.0.6+9-jvmci-19.3-b07, mixed mode, sharing)
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.4.1.Final
• Build tool (ie. output of mvnw --version or gradlew --version):

------------------------------------------------------------
Gradle 6.3
------------------------------------------------------------

Build time:   2020-03-24 19:52:07 UTC
Revision:     bacd40b727b0130eeac8855ae3f9fd9a0b207c60

Kotlin:       1.3.70
Groovy:       2.5.10
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.6 (Oracle Corporation 11.0.6+9-jvmci-19.3-b07)
OS:           Mac OS X 10.15.1 x86_64

Additional context
(Add any other context about the problem here.)

[gsmet]

@AwesomeIbex AFAICS it's fixed in master. At least with the master I have deployed currently on my laptop.

Will try to test it again with latest master then once I have backported everything we want to backport for 1.4.2.Final and see how it goes.

[AwesomeIbex]

@gsmet awesome, i'll wait for 1.4.2 :)

[gsmet]

OK, well, the bad news is that it doesn't look fixed in master and it got even worse. I'll let you know how it goes.

[gsmet]

/cc @geoand

[geoand]

I'll take a look.

[geoand]

Problem seems to be more general, Liquibase is just running into it. See attached screenshot from the debugger:

Lookind into it now.

[geoand]

I looked into this and the problem seems to come down to two things:

• RuntimeUpdatesProcessor.checkForFileChange copies resources into the classes output (build/classes/java/main/)
• Quarkus Runtime Classloader obviously loads the resource from that location, but we have Quarkus Base Runtime Classloader which also loads the resource from build/resources/main/db/changeLog.xml.

I don't know what the proper fix is here,

@aloubyansky @stuartwdouglas WDYT?

Edit: For Maven this isn't an issue because there the output of the classes and resources is the same directory.

[aloubyansky]

This is for the dev mode, right? I'll need to check what happens in this case but Gradle keeps the classes and resources dirs separate, so we shouldn't really be copying resources to the classes dir. But the way the dev mode currently works in Gradle we actually still merge them in a tmp dir. We need to enhance our dev mode setup to respect the native Gradle layout. I can have a look into this issue.

[geoand]

Yes dev mode only