Quarkus Community Call - 2026-09-01

[cescoffier]

Hello,

Yesterday, we had our Quarkus community call after the summer break. Here is a short summary. You can find the complete minutes (including the recording) on the Quarkus community call minutes.

Recap:

Four security advisories were published just before the call; check the Quarkus project advisory list to see if you are affected; releases are on the way.

Clement Guillot (Spio) presented rules_quarkus (https://github.com/clementguillot/rules_quarkus), a project that brings Quarkus application support to the Bazel build system. Bazel's entry point is a bash script rather than a JVM process, so the team built a dedicated CLI called Quarkifier to bootstrap the Quarkus augmentation pipeline inside a Bazel action. The project already supports fast-jar and native image builds (GraalVM Community Edition), dev mode with hot reload (including codegen inputs like .proto and Avro .avsc files), code coverage, and multi-module applications. Dependency resolution uses Coursier to produce a JSON dependency tree that achieves strict parity with the Maven dependency graph, which was verified live via the Dev UI dependency tab.

The demo featured a multi-module producer/consumer application communicating via gRPC with a PostgreSQL-backed consumer, showing that Dev Services, extension discovery, REST, and OpenAPI all work correctly under Bazel. Bazel's toolchain management (auto-downloading JDK and GraalVM versions) and remote caching of build outputs (including Maven dependencies) were also highlighted.

Alexey Loubyansky raised an important design question: the current implementation relies on internal Quarkus APIs (augmentation/bootstrap classes) whose signatures change between minor versions, making maintenance costly. Rather than stabilizing those private APIs, Alexey proposed stepping back to understand the integration needs holistically and designing purpose-built, maintainable APIs for third-party build tool integration. Clement Escoffier also noted that builder image SHAs, Java vendor recommendations, and other constants change frequently and proposed publishing them in a shared artifact.

The group agreed to move rules_quarkus into the Quarkiverse organization and to set up ecosystem CI so that changes on the Quarkus main branch are automatically tested against the Bazel integration. Clement Guillot will document the Quarkifier's version-support mechanism and list all consumed internal APIs to facilitate the API design discussion.

The next community call is in two weeks and will focus on Gradle.

And again, thanks @clementguillot for the very interesting presentation!