Skip to content

Commit 5a828b6

Browse files
actions-useractions-user
committed
Sync working groups
1 parent d687730 commit 5a828b6

1 file changed

Lines changed: 95 additions & 95 deletions

File tree

‎_data/wg.yaml‎

Lines changed: 95 additions & 95 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,100 @@
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-05-19
92+
last-update-date: 2026-04-20
93+
last-update: |
94+
Working group started.
95+
point-of-contact: "@maxandersen"
96+
proposal: https://github.com/quarkusio/quarkus/discussions/53667
97+
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394
398
- title: "Spring-Style Testing"
499
board-url: "https://github.com/orgs/quarkusio/projects/60"
5100
short-description: |
@@ -365,101 +460,6 @@ working-groups:
365460
The team closed out significant work on the Vert.x 5 upgrade and migration of its core extension for Quarkus 4. New tasks include updating Vert.x configuration, reworking CI, and addressing Kafka Kerberos authentication in native mode. We're also defining OpenTelemetry trace sampling defaults and looking into extension modularity.
366461
367462
(This status update was automatically generated using AI.)
368-
- title: "Quarkus Terminal"
369-
board-url: "https://github.com/orgs/quarkusio/projects/77"
370-
short-description: |
371-
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.
372-
readme: |
373-
<h2>The Problem</h2>
374-
<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>
375-
<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>
376-
<p>We currently have terminal-related functionality scattered across multiple libraries with overlapping concerns and inconsistent trade-offs:</p>
377-
<ul>
378-
<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>
379-
<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>
380-
<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>
381-
<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>
382-
</ul>
383-
<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>
384-
<h2>The Proposed Solution</h2>
385-
<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>
386-
<ol>
387-
<li>
388-
<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>
389-
</li>
390-
<li>
391-
<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>
392-
</li>
393-
<li>
394-
<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>
395-
</li>
396-
<li>
397-
<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>
398-
</li>
399-
</ol>
400-
<h2>Definition of Done</h2>
401-
<ul>
402-
<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>
403-
<li>DevShell - Integrated use of TamboUI (or similar) into Quarkus dev mode and/or dev shell in a visible, demoable way.</li>
404-
<li>A path for building TamboUI based Quarkus applications with hotreload and native image, delivered as an extension.</li>
405-
<li>Updated CLI story: Æsh extension direction clarified, optional picocli improvements landed (startup, native, reflection), and a documented decision on a third alternative.</li>
406-
<li>Documented patterns and supporting code for CLI-args-vs-config integration and TUI-vs-dev-mode lifecycle coexistence.</li>
407-
<li>ADRs covering the key design decisions across all four tracks.</li>
408-
<li>Documentation on quarkus.io, plus at least one blog post and one demo/video.</li>
409-
</ul>
410-
<h2>Scope of Work</h2>
411-
<p><strong>In scope:</strong></p>
412-
<ul>
413-
<li>Exploration and design of the ansi/terminal layer.</li>
414-
<li>TamboUI-based exploration of TUI in dev mode / dev shell, and a Quarkus extension enabling application TUIs.</li>
415-
<li>Æsh extension direction and alignment.</li>
416-
<li>Picocli optimizations (native image, startup, reflection config).</li>
417-
<li>Evaluation of a potential lighter CLI alternative.</li>
418-
<li>Integration of CLI argument parsing with the Quarkus config system.</li>
419-
<li>Lifecycle patterns for full-screen TUI applications, including dev mode coexistence and main-thread handling.</li>
420-
<li>Native image support across the tracks.</li>
421-
<li>Documentation, ADRs, samples.</li>
422-
</ul>
423-
<p><strong>Out of scope:</strong></p>
424-
<ul>
425-
<li>Rewriting Æsh or JLine internals beyond what the tracks require.</li>
426-
<li>GUI or web-based dev UI work (covered by other efforts).</li>
427-
<li>Shell scripting languages or REPL language design.</li>
428-
<li>Replacing picocli or Æsh as user-facing choices — both remain supported.</li>
429-
</ul>
430-
<h2>Organizing the Work</h2>
431-
<h3>Communication and Transparency</h3>
432-
<ul>
433-
<li>Coordination via a dedicated GitHub Project spanning the relevant repositories.</li>
434-
<li>Discussion in GitHub Discussions on <code>quarkusio/quarkus</code> for cross-cutting topics; implementation issues on the individual repos.</li>
435-
<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>
436-
</ul>
437-
<h3>Potential Outcomes &amp; Deliverables</h3>
438-
<ul>
439-
<li>A direction (and, where warranted, code) for the ansi/terminal layer.</li>
440-
<li>TamboUI-powered Quarkus dev mode / dev shell enhancements.</li>
441-
<li>A Quarkiverse extension for building TUIs.</li>
442-
<li>Updated Æsh extension.</li>
443-
<li>Picocli extension improvements (startup, native, reflection).</li>
444-
<li>Documented and supported patterns for CLI args ↔ Quarkus config, and for TUI lifecycle coexistence with dev mode.</li>
445-
<li>ADRs across the tracks.</li>
446-
<li>Blog post + demo/video.</li>
447-
</ul>
448-
<ul>
449-
<li>Point of contact: @maxandersen</li>
450-
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/53667</li>
451-
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394">Zulip</a></li>
452-
</ul>
453-
status: on track
454-
lts: false
455-
completed: false
456-
last-activity: 2026-05-17
457-
last-update-date: 2026-04-20
458-
last-update: |
459-
Working group started.
460-
point-of-contact: "@maxandersen"
461-
proposal: https://github.com/quarkusio/quarkus/discussions/53667
462-
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Quarkus.20Terminal/with/587817394
463463
- title: "Quarkus Data"
464464
board-url: "https://github.com/orgs/quarkusio/projects/50"
465465
short-description: |

0 commit comments

Comments
 (0)