Quarkus Community Call Notes - 2026-04-28

[cescoffier]

Hello,

On Tuesday, we held our public Quarkus community call focused on the evolution of our extension resolver and dependency management.

You can find the complete minutes (including the recording) here: https://docs.google.com/document/d/1TgFZsuOQo9qZ4CnQII5LHhQVgMC6YsVMs1UJIAJooyM/edit?tab=t.0

Recap:

The session centered on how Quarkus should handle "missing capabilities." For instance, when an extension like Narayana requires a REST stack that isn't present, should Quarkus pick a default for you, or should it fail the build?

Alexey Loubyansky proposed a model in which the Quarkus Platform defines "default providers" for specific capabilities (e.g., defaulting to Jackson if no JSON provider is available). This aims to balance ease of use with the need for deterministic, offline-capable builds. However, Sanne Grinovero and Max Rydahl Andersen voiced caution against "resolver magic," emphasizing that enterprise users often prefer explicit control to avoid dependency explosion.

The consensus moved toward Guided Resolution: providing high-quality, actionable error messages that tell the user exactly what is missing and how to fix it, potentially using the Quarkus CLI to prompt for choices in Dev Mode.

Finally, David Lloyd gave a brief update on the Modular Quarkus (JPMS) effort, which is nearing a mergeable state but faces some hurdles with testing infrastructure. We will do a deep dive on this on May 12th!