Skip to content

Commit dd82fa3

Browse files
actions-useractions-user
committed
Sync working groups
1 parent 60306d0 commit dd82fa3

1 file changed

Lines changed: 97 additions & 97 deletions

File tree

‎_data/wg.yaml‎

Lines changed: 97 additions & 97 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,102 @@
11
---
22
working-groups:
3+
- title: "Quarkus Terminal"
4+
board-url: "https://github.com/orgs/quarkusio/projects/77"
5+
short-description: |
6+
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.
7+
readme: |
8+
<h2>The Problem</h2>
9+
<p>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.</p>
10+
<p>Quarkus dev mode itself is quite a fancy TUI but its not easy to do similar in Quarkus applications in a consistent way.</p>
11+
<p>We currently have terminal-related functionality scattered across multiple libraries with overlapping concerns and inconsistent trade-offs:</p>
12+
<ul>
13+
<li>Æsh and JLine both ship &quot;complete&quot; 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.</li>
14+
<li>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.</li>
15+
<li>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.</li>
16+
<li>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 <code>quarkus.application.version</code> from <code>@Command</code> 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.</li>
17+
</ul>
18+
<p>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.</p>
19+
<h2>The Proposed Solution</h2>
20+
<p>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.</p>
21+
<ol>
22+
<li>
23+
<p><strong>ansi/terminal</strong> — 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.</p>
24+
</li>
25+
<li>
26+
<p><strong>TUI</strong> 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.</p>
27+
</li>
28+
<li>
29+
<p><strong>CLI</strong> 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.</p>
30+
</li>
31+
<li>
32+
<p><strong>Startup &amp; lifecycle</strong> define clean patterns for terminal-first Quarkus applications: how CLI argument parsing interacts with the Quarkus config system (so flags, env, and <code>application.properties</code> compose predictably), and how TUI/full-screen modes coexist with dev mode, the main thread, and Quarkus' startup/shutdown lifecycle without fighting each other.</p>
33+
</li>
34+
</ol>
35+
<h2>Definition of Done</h2>
36+
<ul>
37+
<li>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.</li>
38+
<li>DevShell - Integrated use of TamboUI (or similar) into Quarkus dev mode and/or dev shell in a visible, demoable way.</li>
39+
<li>A path for building TamboUI based Quarkus applications with hotreload and native image, delivered as an extension.</li>
40+
<li>Updated CLI story: Æsh extension direction clarified, optional picocli improvements landed (startup, native, reflection), and a documented decision on a third alternative.</li>
41+
<li>Documented patterns and supporting code for CLI-args-vs-config integration and TUI-vs-dev-mode lifecycle coexistence.</li>
42+
<li>ADRs covering the key design decisions across all four tracks.</li>
43+
<li>Documentation on quarkus.io, plus at least one blog post and one demo/video.</li>
44+
</ul>
45+
<h2>Scope of Work</h2>
46+
<p><strong>In scope:</strong></p>
47+
<ul>
48+
<li>Exploration and design of the ansi/terminal layer.</li>
49+
<li>TamboUI-based exploration of TUI in dev mode / dev shell, and a Quarkus extension enabling application TUIs.</li>
50+
<li>Æsh extension direction and alignment.</li>
51+
<li>Picocli optimizations (native image, startup, reflection config).</li>
52+
<li>Evaluation of a potential lighter CLI alternative.</li>
53+
<li>Integration of CLI argument parsing with the Quarkus config system.</li>
54+
<li>Lifecycle patterns for full-screen TUI applications, including dev mode coexistence and main-thread handling.</li>
55+
<li>Native image support across the tracks.</li>
56+
<li>Documentation, ADRs, samples.</li>
57+
</ul>
58+
<p><strong>Out of scope:</strong></p>
59+
<ul>
60+
<li>Rewriting Æsh or JLine internals beyond what the tracks require.</li>
61+
<li>GUI or web-based dev UI work (covered by other efforts).</li>
62+
<li>Shell scripting languages or REPL language design.</li>
63+
<li>Replacing picocli or Æsh as user-facing choices — both remain supported.</li>
64+
</ul>
65+
<h2>Organizing the Work</h2>
66+
<h3>Communication and Transparency</h3>
67+
<ul>
68+
<li>Coordination via a dedicated GitHub Project spanning the relevant repositories.</li>
69+
<li>Discussion in GitHub Discussions on <code>quarkusio/quarkus</code> for cross-cutting topics; implementation issues on the individual repos.</li>
70+
<li>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.</li>
71+
</ul>
72+
<h3>Potential Outcomes &amp; Deliverables</h3>
73+
<ul>
74+
<li>A direction (and, where warranted, code) for the ansi/terminal layer.</li>
75+
<li>TamboUI-powered Quarkus dev mode / dev shell enhancements.</li>
76+
<li>A Quarkiverse extension for building TUIs.</li>
77+
<li>Updated Æsh extension.</li>
78+
<li>Picocli extension improvements (startup, native, reflection).</li>
79+
<li>Documented and supported patterns for CLI args ↔ Quarkus config, and for TUI lifecycle coexistence with dev mode.</li>
80+
<li>ADRs across the tracks.</li>
81+
<li>Blog post + demo/video.</li>
82+
</ul>
83+
<ul>
84+
<li>Point of contact: @maxandersen</li>
85+
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/53667</li>
86+
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394">Zulip</a></li>
87+
</ul>
88+
status: on track
89+
lts: false
90+
completed: false
91+
last-activity: 2026-06-02
92+
last-update-date: 2026-05-26
93+
last-update: |
94+
The Quarkus Terminal team is looking into new CLI parsing options, exploring a switch from picocli to aesh. We're also checking out a Tamboui extension that integrates with the Quarkus lifecycle for hotreload capabilities.
95+
96+
(This status update was automatically generated using AI.)
97+
point-of-contact: "@maxandersen"
98+
proposal: https://github.com/quarkusio/quarkus/discussions/53667
99+
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394
3100
- title: "Quarkus 4"
4101
board-url: "https://github.com/orgs/quarkusio/projects/51"
5102
short-description: |
@@ -372,103 +469,6 @@ working-groups:
372469
point-of-contact: "@phillip-kruger"
373470
proposal: https://github.com/quarkusio/quarkus/discussions/53093#discussioncomment-16271096
374471
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/wg-dev-star/with/581636141
375-
- title: "Quarkus Terminal"
376-
board-url: "https://github.com/orgs/quarkusio/projects/77"
377-
short-description: |
378-
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.
379-
readme: |
380-
<h2>The Problem</h2>
381-
<p>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.</p>
382-
<p>Quarkus dev mode itself is quite a fancy TUI but its not easy to do similar in Quarkus applications in a consistent way.</p>
383-
<p>We currently have terminal-related functionality scattered across multiple libraries with overlapping concerns and inconsistent trade-offs:</p>
384-
<ul>
385-
<li>Æsh and JLine both ship &quot;complete&quot; 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.</li>
386-
<li>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.</li>
387-
<li>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.</li>
388-
<li>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 <code>quarkus.application.version</code> from <code>@Command</code> 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.</li>
389-
</ul>
390-
<p>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.</p>
391-
<h2>The Proposed Solution</h2>
392-
<p>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.</p>
393-
<ol>
394-
<li>
395-
<p><strong>ansi/terminal</strong> — 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.</p>
396-
</li>
397-
<li>
398-
<p><strong>TUI</strong> 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.</p>
399-
</li>
400-
<li>
401-
<p><strong>CLI</strong> 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.</p>
402-
</li>
403-
<li>
404-
<p><strong>Startup &amp; lifecycle</strong> define clean patterns for terminal-first Quarkus applications: how CLI argument parsing interacts with the Quarkus config system (so flags, env, and <code>application.properties</code> compose predictably), and how TUI/full-screen modes coexist with dev mode, the main thread, and Quarkus' startup/shutdown lifecycle without fighting each other.</p>
405-
</li>
406-
</ol>
407-
<h2>Definition of Done</h2>
408-
<ul>
409-
<li>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.</li>
410-
<li>DevShell - Integrated use of TamboUI (or similar) into Quarkus dev mode and/or dev shell in a visible, demoable way.</li>
411-
<li>A path for building TamboUI based Quarkus applications with hotreload and native image, delivered as an extension.</li>
412-
<li>Updated CLI story: Æsh extension direction clarified, optional picocli improvements landed (startup, native, reflection), and a documented decision on a third alternative.</li>
413-
<li>Documented patterns and supporting code for CLI-args-vs-config integration and TUI-vs-dev-mode lifecycle coexistence.</li>
414-
<li>ADRs covering the key design decisions across all four tracks.</li>
415-
<li>Documentation on quarkus.io, plus at least one blog post and one demo/video.</li>
416-
</ul>
417-
<h2>Scope of Work</h2>
418-
<p><strong>In scope:</strong></p>
419-
<ul>
420-
<li>Exploration and design of the ansi/terminal layer.</li>
421-
<li>TamboUI-based exploration of TUI in dev mode / dev shell, and a Quarkus extension enabling application TUIs.</li>
422-
<li>Æsh extension direction and alignment.</li>
423-
<li>Picocli optimizations (native image, startup, reflection config).</li>
424-
<li>Evaluation of a potential lighter CLI alternative.</li>
425-
<li>Integration of CLI argument parsing with the Quarkus config system.</li>
426-
<li>Lifecycle patterns for full-screen TUI applications, including dev mode coexistence and main-thread handling.</li>
427-
<li>Native image support across the tracks.</li>
428-
<li>Documentation, ADRs, samples.</li>
429-
</ul>
430-
<p><strong>Out of scope:</strong></p>
431-
<ul>
432-
<li>Rewriting Æsh or JLine internals beyond what the tracks require.</li>
433-
<li>GUI or web-based dev UI work (covered by other efforts).</li>
434-
<li>Shell scripting languages or REPL language design.</li>
435-
<li>Replacing picocli or Æsh as user-facing choices — both remain supported.</li>
436-
</ul>
437-
<h2>Organizing the Work</h2>
438-
<h3>Communication and Transparency</h3>
439-
<ul>
440-
<li>Coordination via a dedicated GitHub Project spanning the relevant repositories.</li>
441-
<li>Discussion in GitHub Discussions on <code>quarkusio/quarkus</code> for cross-cutting topics; implementation issues on the individual repos.</li>
442-
<li>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.</li>
443-
</ul>
444-
<h3>Potential Outcomes &amp; Deliverables</h3>
445-
<ul>
446-
<li>A direction (and, where warranted, code) for the ansi/terminal layer.</li>
447-
<li>TamboUI-powered Quarkus dev mode / dev shell enhancements.</li>
448-
<li>A Quarkiverse extension for building TUIs.</li>
449-
<li>Updated Æsh extension.</li>
450-
<li>Picocli extension improvements (startup, native, reflection).</li>
451-
<li>Documented and supported patterns for CLI args ↔ Quarkus config, and for TUI lifecycle coexistence with dev mode.</li>
452-
<li>ADRs across the tracks.</li>
453-
<li>Blog post + demo/video.</li>
454-
</ul>
455-
<ul>
456-
<li>Point of contact: @maxandersen</li>
457-
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/53667</li>
458-
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394">Zulip</a></li>
459-
</ul>
460-
status: on track
461-
lts: false
462-
completed: false
463-
last-activity: 2026-06-02
464-
last-update-date: 2026-05-26
465-
last-update: |
466-
The Quarkus Terminal team is looking into new CLI parsing options, exploring a switch from picocli to aesh. We're also checking out a Tamboui extension that integrates with the Quarkus lifecycle for hotreload capabilities.
467-
468-
(This status update was automatically generated using AI.)
469-
point-of-contact: "@maxandersen"
470-
proposal: https://github.com/quarkusio/quarkus/discussions/53667
471-
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394
472472
- title: "Quarkus 3.15 LTS"
473473
board-url: "https://github.com/orgs/quarkusio/projects/28"
474474
short-description: |

0 commit comments

Comments
 (0)