Quarkus 3.31.0.CR1 released

[Guillaume Smet]

Hi,

We released Quarkus 3.31.0.CR1.

Changelog is here:

https://github.com/quarkusio/quarkus/releases/tag/3.31.0.CR1

There are a few known issues:

- if you try to create a new app or test the new quarkus Maven packaging, please use the `io.quarkus` Maven plugin as the `io.quarkus.platform` plugin (which is the one that will be used by default in the generated project) doesn't contain a critical file and will fail when using the new quarkus Maven packaging. This is going to be fixed for the final

- you might get a warning saying you need to add <extensions>true</extensions> to your Quarkus Maven plugin, even if it's already there. Please ignore it for now, we are still iterating on a fix for this one.

Please try to upgrade your applications and report back:
- if everything is going well, just post a reply to this thread
- if you encounter issues, please open a GitHub issue in our tracker with a simple reproducer

We will build the final core artifacts next Wednesday.

Thanks!

--

The Quarkus dev team

[Marco Bungart]

Hi!

we have one issue in quarkus-artemis.

In two of our tests, rest-assured seems to think that the http port is set to 0 [1][2]. The port is set in [3] and [4]. We set the port to 0 in all of our tests; I am not entirely sure why this one fails. And this is not a fluke, re-running the pipeline always fails these two tests. Some help would be appreciated.

[1]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/21083706535/job/60642918296#step:4:838
[2]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/21083706535/job/60642918299#step:4:734
[3]: https://github.com/quarkiverse/quarkus-artemis/blob/quarkus-3.31.0.CR1/integration-tests/camel-jms/with-default-and-named/src/main/resources/application.properties#L5
[4]: https://github.com/quarkiverse/quarkus-artemis/blob/quarkus-3.31.0.CR1/integration-tests/ra/src/main/resources/application.properties#L1

Thanks in advance,

Marco

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9EPZxBf_kJR8ZJjcQ2QC8DFB-FBUjKVhUUmkoPoJF4-A%40mail.gmail.com.

[Guillaume Smet]

Hi Marco,

Thanks for testing. Could you please open a bug. I wonder if it could be related to the work done by Roberto on the value registry.

Thanks.

-- 

Guillaume

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/a9b37657-8905-450d-a12a-b4abad845439%40googlemail.com.

[Robert Stupp]

Hi,

I ran the "Nessie Quarkus CR" testing workflow [1] against a branch
with updates required in the Nessie code base. After some fixes due to
our own code, the quarkus-build task is failing.
I haven't completely figured out why, because there's no reasonable
error message printed out (something that makes sense to me) and
nothing gets logged to a file. All I have is a ClassNotFoundException
for io.quarkus.deployment.builditem.DevServicesConfigResultBuildItem
[2]
Initially I suspected io.quarkus:quarkus-junit4-mock:3.25.0, which is
pulled in transitively by some Quarkus extensions, but banning that
dependency didn't help.
Is it fair to assume that it's caused by some not-yet-updated
extension? Maybe io.quarkiverse.loggingsentry or
io.quarkiverse.vault:quarkus-vault or io.quarkiverse.azureservices?

Robert

[1] https://github.com/projectnessie/nessie/actions/runs/21072375426
[2] https://scans.gradle.com/s/ahuvc4735mie4/failures?expanded-stacktrace=WyIwLTEtMi0zLTQiLCIwLTEtMi0zIiwiMC0xLTIiLCIwIiwiMC0xIl0#1

[Guillaume Smet]

Which extension is dragging quarkus-junit4-mock?

Also which one requires DevServicesConfigResultBuildItem? I think it's gone now so we will have to update them.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAM_p_fuXh2w8CFYwG8Vr6rZF7R9t%2Bb3h-L_q9AQQJ0rQnRXKAQ%40mail.gmail.com.

[Guillaume Smet]

In the Quarkiverse, I can see Vault and Kerberos.

[Guillaume Smet]

Vault has a PR here: https://github.com/quarkiverse/quarkus-vault/pull/467

[V. Sevel]

for vault, I have just released a 4.5.0.CR1

[Robert Stupp]

Just gathered the dependency tree with quarkus-vault 4.5.0.CR1 and can
confirm that the junit4 dependency is gone and our workflow's able to
proceed to tests.

It's hitting a failure that the system properties quarkus.http.port or
quarkus.http.test-port are no longer present for tests.
The only system property that is set is
quarkus-internal-test.serialized-app-model.path.
Link to the workflow-run for Quarkus 3.31.CR1 + Quarkus-Vault
4.5.0.CR1: https://github.com/projectnessie/nessie/actions/runs/21135520579
- Catalogs.java:36 contains the code
'Integer.getInteger("quarkus.http.port")'.
Link to the Gradle build scan:
https://scans.gradle.com/s/4dpe6he6cj6eq/tests/task/:nessie-quarkus:test/details/org.projectnessie.server.catalog.TestGcsIcebergCatalog/testUpdateNamespaceProperties()?expanded-stacktrace=WyIwIl0&top-execution=1

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/4542f91c-3101-4f3b-a8e0-b7cce9872035n%40googlegroups.com.

[Marco Bungart]

Done: https://github.com/quarkusio/quarkus/issues/52069

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9qFyPF%2Bf-1JC7U%2B_4gHr6k_nVZhbB3Jx6ZcZ43Fx-ruA%40mail.gmail.com.

[Sergey Beryozkin]

On Sun, Jan 18, 2026 at 5:38 PM Guillaume Smet <guillau...@gmail.com> wrote:

In the Quarkiverse, I can see Vault and Kerberos.

I removed a quarkus-junit-mock dependency in quarkus-kerberos, and released 2.3.0

Thanks

 

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9NrEJLOf8c2%3DKkY5QHHZ5HDo2wJJT7D2w3CfzzPZzv5g%40mail.gmail.com.

[Holly Cummins]

It looks like the Kerberos extension will also need a dev services update, unless we revert the removal of the deprecated classes. With hindsight, I should have checked the Quarkiverse first, rather than assuming 2021 was so long ago that it would be safe to remove. 

 

--
Holly Cummins
Partner Engineer, Senior Principal Quarkus Software Engineer, Java Champion
Red Hat 

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfU8%2BvjVDdHWqPBihbgaygS35g2UXZfS0ev38L29pd6CUw%40mail.gmail.com.

[Sergey Beryozkin]

On Mon, Jan 19, 2026 at 12:33 PM 'Holly Cummins' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

It looks like the Kerberos extension will also need a dev services update, unless we revert the removal of the deprecated classes. With hindsight, I should have checked the Quarkiverse first, rather than assuming 2021 was so long ago that it would be safe to remove. 

 

It is grand 🙂, I'll take care of replacing those gone build items when quarkus-kerberos will be updated to the release from the current Quarkus  main

Thanks

 

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/5C4ABC3B-8E4A-4F8B-A3A9-8888DEAEF692%40redhat.com.

[Guillaume Smet]

I will release 3.31.0 core artifacts on Wednesday. You will be able to update quarkus-kerberos after that.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfVzCETZogfO4%2BSkXj9vugMtv-9Gnc%3D18OPRpdtT_t%2B5rw%40mail.gmail.com.

[Roberto Cortez]

Hi Robert,

Due to https://github.com/quarkusio/quarkus/pull/51867, we introduced a small breaking change, where quarkus.http.port or quarkus.http.test-port cannot be queried directly using System Properties. You must use Quarkus Config System via Config or SmallRyeConfig, or use a new API HttpServer to retrieve this information: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.31#configuration

Sorry for the inconvenience.

Cheers,

Roberto

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAM_p_fsR%2BGPsgTa0fAWNmwJ_eMN4gKzocLCN9SfJzmn%3DQLRnMA%40mail.gmail.com.

[V. Sevel]

if the business endpoint class is moved in the default package, we get this error at startup:

Caused by: java.lang.ClassNotFoundException: GreetingResource_Bean

        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)

        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)

        at io.quarkus.bootstrap.runner.RunnerClassLoader.loadClass(RunnerClassLoader.java:136)

        at io.quarkus.bootstrap.runner.RunnerClassLoader.loadClass(RunnerClassLoader.java:87)

        ... 16 more

since this is not a common and/or recommended practice, I do not if this is worth an issue.

Vincent 

[Guillaume Smet]

@vvs...@gmail.com

 this is new with 3.31.0.CR1? If so, I think we want an issue, if possible with a small reproducer.

Thanks!

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/a5001275-a79d-4c69-b87f-6b6d8b86cf39n%40googlegroups.com.

[V. Sevel]

here it is: https://github.com/quarkusio/quarkus/issues/52073

[Robert Stupp]

Hi,

no problem - that's what a CR is for ;)

The approach is totally fine and I like it.
And I understand the reason for this change.
I just think it's worth calling this out in the "release highlights".
IIRC there were some docs or guides mentioning the system properties -
but it's looong ago, so I cannot say where we got the
system-properties approach from.

One can always use the "legacy way" via the smallrye-config API
'ConfigProvider.getConfig().getConfigValue()', which is a working
replacement even for static-initialization cases, where neither
'@Inject' the 'HttpServer' nor a test/beforeeach/beforeall-function
parameter works.
We have one case where a custom JUnit extension needs it to provide
test URLs, and JUnit extensions cannot query other JUnit extensions.

For integration tests, only the HTTP port seems to be available via
HttpServer.getPort(), getManagmentPort() always yields -1 and
getLocalBaseUri() throws :(

(Sorry, I have written this email some time ago, but forgot to hit the
"send" button)

On Mon, Jan 19, 2026 at 3:41 PM 'Roberto Cortez' via Quarkus

Development mailing list <quark...@googlegroups.com> wrote:
>

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/E11AC70B-8331-4AD6-BA21-69F89E864DA1%40yahoo.com.

[Robert Stupp]

Another thing I observed, but not sure whether it's new or not.

Assume there are some integration test classes, each with a different
test-profile with different sets of configuration-overrides.
Say IntTestA.Profile sets configs foo=bar and bar=baz -
IntTestB.Profile sets configs x=y.
What I see is that the configurations from test-profiles of earlier
run integration tests "leak" into the later ran integration tests -
like IntTestB sees foo=bar + bar=baz.

[Roberto Cortez]

Yes, this is a known issue reported in:

https://github.com/quarkusio/quarkus/issues/27996

We didn’t have a way to fix it until now, with the work done in https://github.com/quarkusio/quarkus/pull/51209, so I should be submitting a fix soon.

Cheers,

Roberto

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAM_p_fukyN%2B3Z4noyGE3BydeZW3tUVe6rJK1ginVFfS0adhJNA%40mail.gmail.com.