Open pdolezal opened 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.
This looks a bit different from what @metacosm had. I'll look into it.
Thanks
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.
The project config and the fix will be different though. For example, as a quick workaround
mvn compile quarkus:dev
will work.
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
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.
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).
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
That looks like a different issue @ivivanov-bg Please create a new one describing your use-case including a complete stack trace. Thanks.
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.
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.
Describe the bug
After updating a project from Quarkus 3.1.x to 3.2.x,
mvn quarkus:dev
fails to start the application: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 withquarkus: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:
mvn quarkus:dev
in the project's root folder.quarkus.version
property inpom.xml
to3.1.3.Final
(the latest version that worked).mvn quarkus:dev
in the project's root folder again.Notes:
mvn clean compile quarkus:dev
succeeds.flatten-maven-plugin
definitely helps.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 offlatten-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
orver
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
orgradlew --version
)No response
Additional information
No response