Working Group Proposal - Quarkus Terminal

[maxandersen]

WG - Quarkus Terminal

Objective:

The main objective of this working group is to establish a cohesive foundation for terminal-based experiences in Quarkus.
Spanning console I/O, TUIs, CLI parsing, and startup/lifecycle integration**. Enable Quarkus itself and applications built on it to have a consistent, lightweight stack to build on.

The Problem

Quarkus early start was focus most on web applications and microservices. Over the years we enabled things like command mode and CLI parsing (mainly using Picocli) but its been more a organic adaption than a clean and extendable setup.

Quarkus dev mode itself is quite a fancy TUI but its not easy to do similar in Quarkus applications in a consistent way.

We currently have terminal-related functionality scattered across multiple libraries with overlapping concerns and inconsistent trade-offs:

• Æsh and JLine both ship "complete" stacks (readline, parsing, rendering, history, completion) and pull in more than many consumers need. There is no shared minimal console/ANSI primitive that higher-level libraries can depend on without inheriting a full stack.
• Dev mode and dev shell UX could be significantly richer with a proper TUI layer, but we have no sanctioned approach for devmode nor extension for building TUIs in Quarkus applications.
• The CLI story is split between Æsh (strong on readline/interactive shells) and picocli (strong on argument parsing), with no clear guidance on when to use which, and no shared story around native-image friendliness, startup time, and reflection config.
• The startup phase itself is murky for terminal-heavy apps: there is no clean pattern for CLI argument parsing to interact with Quarkus' config system (exposing picocli options as config sources, reaching quarkus.application.version from @Command annotations, etc.), and TUI-style full-screen applications conflict with dev mode and main-thread assumptions in ways that are not well defined, dev mode partially captures keystrokes destined for the application being a concrete example.

The net effect is duplicated effort, inconsistent behavior across Quarkus-adjacent tooling, missed opportunities in dev mode, and friction for anyone trying to build a terminal-first Quarkus application.

The Proposed Solution

Organize the work into four coordinated tracks under a single working group. The tracks are related but the shape of the shared substrate/results (if any) is an open design question which this working group will try solve.

1. ansi/terminal — explore how to best provide minimal console primitives (terminal detection, ANSI handling, raw/cooked mode, resize, input events, color/style). Whether this is a new library, a refactor of what exists, or a thin facade over JLine/Æsh is itself part of the work.

2. TUI Use TamboUI as a vehicle to explore TUI integration in dev mode and dev shell, and enable application developers to build TUIs in Quarkus. TamboUI is the starting point for exploration, not a predetermined final choice; the track should surface what a good Quarkus TUI story looks like regardless of which library ultimately backs it.

3. CLI clarify and improve the two main CLI paths: an Æsh extension focused on interactive/readline use cases, and picocli optimizations focused on argument parsing, startup, and native image. Evaluate what can be done for startup impact.

4. Startup & lifecycle define clean patterns for terminal-first Quarkus applications: how CLI argument parsing interacts with the Quarkus config system (so flags, env, and application.properties compose predictably), and how TUI/full-screen modes coexist with dev mode, the main thread, and Quarkus' startup/shutdown lifecycle without fighting each other.

Definition of Done

• A documented direction for the ansi/terminal layer — whether that means a new library, a consolidation, or a decision that the status quo plus minor changes is sufficient.
• DevShell - Integrated use of TamboUI (or similar) into Quarkus dev mode and/or dev shell in a visible, demoable way.
• A path for building TamboUI based Quarkus applications with hotreload and native image, delivered as an extension.
• Updated CLI story: Æsh extension direction clarified, optional picocli improvements landed (startup, native, reflection), and a documented decision on a third alternative.
• Documented patterns and supporting code for CLI-args-vs-config integration and TUI-vs-dev-mode lifecycle coexistence.
• ADRs covering the key design decisions across all four tracks.
• Documentation on quarkus.io, plus at least one blog post and one demo/video.

Scope of Work

In scope:

• Exploration and design of the ansi/terminal layer.
• TamboUI-based exploration of TUI in dev mode / dev shell, and a Quarkus extension enabling application TUIs.
• Æsh extension direction and alignment.
• Picocli optimizations (native image, startup, reflection config).
• Evaluation of a potential lighter CLI alternative.
• Integration of CLI argument parsing with the Quarkus config system.
• Lifecycle patterns for full-screen TUI applications, including dev mode coexistence and main-thread handling.
• Native image support across the tracks.
• Documentation, ADRs, samples.

Out of scope:

• Rewriting Æsh or JLine internals beyond what the tracks require.
• GUI or web-based dev UI work (covered by other efforts).
• Shell scripting languages or REPL language design.
• Replacing picocli or Æsh as user-facing choices — both remain supported.

Organizing the Work

1. Communication and Transparency

• Coordination via a dedicated GitHub Project spanning the relevant repositories.
• Discussion in GitHub Discussions on quarkusio/quarkus for cross-cutting topics; implementation issues on the individual repos.
• Work will land across Quarkus core (dev mode, dev shell, lifecycle), Quarkiverse (TUI extension, Æsh extension, picocli extension), and potentially standalone repositories depending on where the ansi/terminal exploration lands.

2. Point of Contact

• Max Rydahl Andersen (@maxandersen)

3. Expected Timeline

• For Quarkus 3.x mainline: have PR's for Aeash and TamboUI merged and enabled
• For Quarkus 4: Have devshell and terminal base line integrated

Potential Outcomes & Deliverables

• A direction (and, where warranted, code) for the ansi/terminal layer.
• TamboUI-powered Quarkus dev mode / dev shell enhancements.
• A Quarkiverse extension for building TUIs.
• Updated Æsh extension.
• Picocli extension improvements (startup, native, reflection).
• Documented and supported patterns for CLI args ↔ Quarkus config, and for TUI lifecycle coexistence with dev mode.
• ADRs across the tracks.
• Blog post + demo/video.

Interested participants

• @dmlloyd
• @quintesse
• @stalep
• @phillip-kruger
• @geoand
• @maxandersen

Existing issues

A non-exhaustive starting set, grouped by track. Worth another sweep (especially area/picocli, area/devmode, area/cli labels) before board creation.

• Initial aesh extension support including ssh and websocket #52714
• Introduce new CLI module inspired by PicoCLI #53201
• Add interactive Terminal UI (TUI) mode for enhanced developer experience #52750
• Picocli command options exposed as ConfigSources #19128
• On Windows in native mode detect proper color handling  #4095
• Command history in dev mode for CLI apps #21594
• Add interactive Terminal UI (TUI) mode for enhanced developer experience #52750

[cescoffier]

Board created: WG - Quarkus Terminal (view)