search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.53k stars 2.61k forks source link

Launching via quarkus:dev fails after upgrading from Quarkus 3.1.x #35527

Open pdolezal opened 1 year ago

pdolezal commented 1 year ago

Describe the bug

After updating a project from Quarkus 3.1.x to 3.2.x, mvn quarkus:dev fails to start the application:

2023-08-24 12:29:34,440 INFO  [io.qua.dep.dev.IsolatedDevModeMain] (main) Attempting to start live reload endpoint to recover from previous Quarkus startup failure
2023-08-24 12:29:35,092 ERROR [io.qua.dep.dev.IsolatedDevModeMain] (main) Failed to start quarkus: io.smallrye.config.ConfigValidationException: Configuration validation failed:
        java.util.NoSuchElementException: SRCFG00011: Could not expand value platform.quarkus.native.builder-image in property quarkus.native.builder-image
        at io.smallrye.config.ConfigMappingProvider.mapConfigurationInternal(ConfigMappingProvider.java:1003)
        at io.smallrye.config.ConfigMappingProvider.lambda$mapConfiguration$3(ConfigMappingProvider.java:959)
        at io.smallrye.config.SecretKeys.doUnlocked(SecretKeys.java:28)
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:959)
        at io.smallrye.config.ConfigMappings.mapConfiguration(ConfigMappings.java:91)
        at io.smallrye.config.SmallRyeConfigBuilder.build(SmallRyeConfigBuilder.java:647)
        at io.quarkus.deployment.configuration.BuildTimeConfigurationReader.initConfiguration(BuildTimeConfigurationReader.java:409)
        at io.quarkus.deployment.ExtensionLoader.loadStepsFrom(ExtensionLoader.java:138)
        at io.quarkus.deployment.QuarkusAugmentor.run(QuarkusAugmentor.java:107)
        at io.quarkus.runner.bootstrap.AugmentActionImpl.runAugment(AugmentActionImpl.java:332)
        at io.quarkus.runner.bootstrap.AugmentActionImpl.createInitialRuntimeApplication(AugmentActionImpl.java:253)
        at io.quarkus.runner.bootstrap.AugmentActionImpl.createInitialRuntimeApplication(AugmentActionImpl.java:60)
        at io.quarkus.deployment.dev.IsolatedDevModeMain.firstStart(IsolatedDevModeMain.java:82)
        at io.quarkus.deployment.dev.IsolatedDevModeMain.accept(IsolatedDevModeMain.java:423)
        at io.quarkus.deployment.dev.IsolatedDevModeMain.accept(IsolatedDevModeMain.java:55)
        at io.quarkus.bootstrap.app.CuratedApplication.runInCl(CuratedApplication.java:138)
        at io.quarkus.bootstrap.app.CuratedApplication.runInAugmentClassLoader(CuratedApplication.java:93)
        at io.quarkus.deployment.dev.DevModeMain.start(DevModeMain.java:131)
        at io.quarkus.deployment.dev.DevModeMain.main(DevModeMain.java:62)

The problem appears with Quarkus 3.3.0 too. There is no problem with building the application (i.e., running mvn package) and running the produced artifact, the problem appears with quarkus:dev only. In this sense it is not an actual development blocker, but it significantly reduces a developer's comfort.

Expected behavior

There should be no regression w.r.t. running quarkus:dev. If the application can be compiled and launched with no errors, quarkus:dev should be capable of compiling and launching it with no errors as well.

Actual behavior

No response

How to Reproduce?

We were able to prepare a small reproducer that can be used to see the regression:

  1. Unpack the project.
  2. Execute mvn quarkus:dev in the project's root folder.
  3. You should see that it fails with the stack trace from above.
  4. Change quarkus.version property in pom.xml to 3.1.3.Final (the latest version that worked).
  5. Execute mvn quarkus:dev in the project's root folder again.
  6. The application should launch without problems.

Notes:

We tried the mvn clean compile quarkus:dev workaround with other projects. All our Quarkus projects are based on the same template, thus have the same structure, same plugin set etc., although they may differ in versions of plugins and dependencies. Regardless of eventual differences, we could not pinpoint other important precursor for the failure than the presence of flatten-maven-plugin. Some projects do work even with the plugin and even without the workaround, for other projects the workaround does not actually work and the only thing that helps is removing the plugin. The reproducer, which is quite minimalistic, shows both, so we hope it is linked to all potential root causes that manifest problems in various projects of ours.

It should be noted that we tried different versions of both Maven and flatten-maven-plugin to no avail (we tried Maven 3.9.* and Maven 3.8.4 and 3.8.6, which were working before). We tried that on Windows and Linux (Ubuntu) and different versions of OpenJDK (mostly OpenJDK 17).

Last, but not least, we experienced similar troubles before, see #27930.

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

geoand commented 1 year ago

cc @aloubyansky @maxandersen @metacosm as this is the same as was discussed on Zulip.

The problem is most likely that the BOM is not properly configured.

aloubyansky commented 1 year ago

This looks a bit different from what @metacosm had. I'll look into it.

geoand commented 1 year ago

Thanks

metacosm commented 1 year ago

This looks a bit different from what @metacosm had. I'll look into it.

The only difference I could spot was that the 2 last items in the stack trace are offset by 2 lines (i.e. in my error the problem is on line 957 and 1001 instead of 959 and 1003, respectively) but that's about it, the rest is exactly the same.

aloubyansky commented 1 year ago

The project config and the fix will be different though. For example, as a quick workaround

mvn compile quarkus:dev

will work.

aloubyansky commented 1 year ago

The cause is the same though, the flatten plugin (according to the config) removes dependencyManagement and we loose the platform config source (among other things). The reason it didn't fail in the mentioned earlier Quarkus versions is that in those Quarkus versions quarkus:dev didn't automatically invoke all the other other Maven goals that were configured in the POM to be executed in phases preceding compile and testCompile

pdolezal commented 1 year ago

The project config and the fix will be different though. For example, as a quick workaround

mvn compile quarkus:dev

will work.

As noted in the report, the workaround works for this reproducer, but not very reliably for other projects – for some it works, for others it does not. I have no idea what the distinguishing factor is.

aloubyansky commented 1 year ago

It's probably the phase in which the flattening plugin is executed and/or whether generate-code goals are configured. We need to to be able to figure out the Quarkus BOMs versions imported in application projects to be able to provide Quarkus version information to Quarkus bootstrap and extensions. The flattening plugin manipulates the POM and also the POM model in memory. If you configure the flattening plugin to leave the dependencyManagement in the POM then it will work.

I'm considering ignoring the flattening plugin when quarkus:dev executes all the Maven plugin goals preceding compile phase (kind of like it was in the last version which worked for you).

ivivanov-bg commented 1 year ago

I'm encountering similar issue when using flattening plugin in quarkus extension. The tests for the deployment module are failing because it can't resolve the module:

mvn clean install -pl module1/runtime,module1/deployment

java.lang.RuntimeException: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for com.ivtechs.test:module1-deployment::jar:${module1.version}null
aloubyansky commented 1 year ago

That looks like a different issue @ivivanov-bg Please create a new one describing your use-case including a complete stack trace. Thanks.

pdolezal commented 11 months ago

Hi, the issue remains even with the latest Quarkus release. But we found at least an acceptable workaround, which does not feel too awkward and which works reliably. Perhaps it would be interesting to someone who experiences same difficulties.

We added in our POM this part:

<profile>
  <!-- Performs a build suitable for debugging -->
  <id>debug</id>

  <build>
    <plugins>
      <plugin>
        <!-- Disable this plugin because it interferes with quarkus:dev -->
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>flatten-maven-plugin</artifactId>

        <executions>
          <execution>
            <id>flatten-process</id>
            <phase>none</phase>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

Running mvn -P debug quarkus:dev works now fine, while the pipeline may continue work with the flattened POM, because other goals are not affected. Anyway, it would be nice if the goal worked out of the box, without such a workaround.

samlof commented 8 months ago

We came across the same problem but packaging didn't work either with newest 3.6.3 version

https://github.com/quarkusio/quarkus/issues/31420#issuecomment-1516460547 fixed it. Added the missing config key to application properties with any value.