Skip to content

Commit bad2bb8

Browse files
actions-useractions-user
committed
Sync working groups
1 parent f7eefd7 commit bad2bb8

File tree

1 file changed

+66
-66
lines changed

1 file changed

+66
-66
lines changed

‎_data/wg.yaml‎

Lines changed: 66 additions & 66 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,71 @@
11
---
22
working-groups:
3+
- title: "Panache.Next"
4+
board-url: "https://github.com/orgs/quarkusio/projects/50"
5+
short-description: |
6+
The primary objective of this working group is to develop the next version of Panache.
7+
readme: |
8+
<h1>Objective</h1>
9+
<p>The main objective of this working group is to bring forth the next version of Panache.</p>
10+
<h1>The Problem</h1>
11+
<p>Panache is great for many things, but over time, we realised the following limitations:</p>
12+
<ul>
13+
<li>We have three distinct versions: Hibernate ORM, Hibernate Reactive and Mongo (blocking and reactive)</li>
14+
<li>It is impossible to use the same entities with Hibernate ORM and Hibernate Reactive</li>
15+
<li>Stateless sessions are not supported</li>
16+
<li>Hibernate Processor annotations, and Jakarta Data are not supported</li>
17+
<li>We have triplicate types such as <code>Sort</code> and <code>Order</code> between Panache, ORM and Jakarta Data</li>
18+
<li>We have two ways to place entity query operations : on the entity itself, or in repositories</li>
19+
<li>Entity query operations require type-system hacks which makes them less type-safe than we want with <code>var</code> and <code>for-each</code> and especially with reactive operations.</li>
20+
</ul>
21+
<h1>The proposed Solution</h1>
22+
<p>We propose a new Panache version that will solve all these issues:</p>
23+
<ul>
24+
<li>Unify all variants in a single module, supporting blocking, reactive, stateless and stateful sessions</li>
25+
<li>Provide an entity toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
26+
<li>Move all entity query operations from the entity class to the repository class</li>
27+
<li>Provide a repository toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
28+
<li>Provide easy access to any type of repository by placing them as nested interfaces in the entity class, via a generated accessor on the entity metamodel class</li>
29+
<li>Provide out of the box accessors for the 4 modes of operation repositories on the entity metamodel class</li>
30+
<li>Support Jakarta Data and Hibernate Processor type-safe annotations</li>
31+
<li>Optional: Support of Mongo via the coming ORM JDBC support</li>
32+
<li>Optional: provide JD repository type alternatives for the missing three modes</li>
33+
<li>Optional: provide a way to convert Panache 1 to Panache.Next</li>
34+
</ul>
35+
<h1>Definition of Done</h1>
36+
<ul>
37+
<li>Deliver the new Panache extension as a <code>stable</code> state (after preview/experimental versions for feedback)</li>
38+
<li>Tests</li>
39+
<li>Documentation</li>
40+
<li>Codestart</li>
41+
<li>REST Data with Panache support</li>
42+
<li>Renarde support</li>
43+
<li>Quarkus Insights</li>
44+
</ul>
45+
<h1>Scope of Work</h1>
46+
<p>It is currently out of scope to retrofit this with the existing Panache modules. This will be a new module with no backward compatibility (although most type-unsafe operations will continue as-is, so you will be familiar with them).</p>
47+
<h1>Organizing the Work</h1>
48+
<h2>Communication and Transparency:</h2>
49+
<p>This will be done via GitHub issues on the Quarkus core project.</p>
50+
<h2>Expected Timeline:</h2>
51+
<p>Most of the R&amp;D and design work has been completed over the last two years. Now remains the task of merging, documenting, testing, and tweaking it until it's complete.</p>
52+
<ul>
53+
<li>Point of contact: @FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</li>
54+
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/48949</li>
55+
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Panache.2ENext/with/529258261">Zulip</a></li>
56+
</ul>
57+
status: on track
58+
lts: false
59+
completed: false
60+
last-activity: 2025-12-15
61+
last-update-date: 2025-10-27
62+
last-update: |
63+
In the last month, the WG - Panache.Next did not close any issues but opened one to address the acceptance of `null` persistence units (PUs) in ORM and HR Panache. This highlights ongoing efforts to refine the next version of Panache, focusing on improving functionality and stability as the group progresses towards its development goals.
64+
65+
(This status update was automatically generated using AI.)
66+
point-of-contact: "@FroMage (@<strong>Stephane Epardaud</strong> on Zulip)"
67+
proposal: https://github.com/quarkusio/quarkus/discussions/48949
68+
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Panache.2ENext/with/529258261
369
- title: "Java 25 support"
470
board-url: "https://github.com/orgs/quarkusio/projects/59"
571
short-description: |
@@ -625,72 +691,6 @@ working-groups:
625691
point-of-contact: "@edeandrea, @aureamunoz , @mkouba"
626692
proposal: https://github.com/quarkusio/quarkus/discussions/49964
627693
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Spring-Style.20Testing.20Compatibility.20for.20Quarkus/with/539471996
628-
- title: "Panache.Next"
629-
board-url: "https://github.com/orgs/quarkusio/projects/50"
630-
short-description: |
631-
The primary objective of this working group is to develop the next version of Panache.
632-
readme: |
633-
<h1>Objective</h1>
634-
<p>The main objective of this working group is to bring forth the next version of Panache.</p>
635-
<h1>The Problem</h1>
636-
<p>Panache is great for many things, but over time, we realised the following limitations:</p>
637-
<ul>
638-
<li>We have three distinct versions: Hibernate ORM, Hibernate Reactive and Mongo (blocking and reactive)</li>
639-
<li>It is impossible to use the same entities with Hibernate ORM and Hibernate Reactive</li>
640-
<li>Stateless sessions are not supported</li>
641-
<li>Hibernate Processor annotations, and Jakarta Data are not supported</li>
642-
<li>We have triplicate types such as <code>Sort</code> and <code>Order</code> between Panache, ORM and Jakarta Data</li>
643-
<li>We have two ways to place entity query operations : on the entity itself, or in repositories</li>
644-
<li>Entity query operations require type-system hacks which makes them less type-safe than we want with <code>var</code> and <code>for-each</code> and especially with reactive operations.</li>
645-
</ul>
646-
<h1>The proposed Solution</h1>
647-
<p>We propose a new Panache version that will solve all these issues:</p>
648-
<ul>
649-
<li>Unify all variants in a single module, supporting blocking, reactive, stateless and stateful sessions</li>
650-
<li>Provide an entity toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
651-
<li>Move all entity query operations from the entity class to the repository class</li>
652-
<li>Provide a repository toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
653-
<li>Provide easy access to any type of repository by placing them as nested interfaces in the entity class, via a generated accessor on the entity metamodel class</li>
654-
<li>Provide out of the box accessors for the 4 modes of operation repositories on the entity metamodel class</li>
655-
<li>Support Jakarta Data and Hibernate Processor type-safe annotations</li>
656-
<li>Optional: Support of Mongo via the coming ORM JDBC support</li>
657-
<li>Optional: provide JD repository type alternatives for the missing three modes</li>
658-
<li>Optional: provide a way to convert Panache 1 to Panache.Next</li>
659-
</ul>
660-
<h1>Definition of Done</h1>
661-
<ul>
662-
<li>Deliver the new Panache extension as a <code>stable</code> state (after preview/experimental versions for feedback)</li>
663-
<li>Tests</li>
664-
<li>Documentation</li>
665-
<li>Codestart</li>
666-
<li>REST Data with Panache support</li>
667-
<li>Renarde support</li>
668-
<li>Quarkus Insights</li>
669-
</ul>
670-
<h1>Scope of Work</h1>
671-
<p>It is currently out of scope to retrofit this with the existing Panache modules. This will be a new module with no backward compatibility (although most type-unsafe operations will continue as-is, so you will be familiar with them).</p>
672-
<h1>Organizing the Work</h1>
673-
<h2>Communication and Transparency:</h2>
674-
<p>This will be done via GitHub issues on the Quarkus core project.</p>
675-
<h2>Expected Timeline:</h2>
676-
<p>Most of the R&amp;D and design work has been completed over the last two years. Now remains the task of merging, documenting, testing, and tweaking it until it's complete.</p>
677-
<ul>
678-
<li>Point of contact: @FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</li>
679-
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/48949</li>
680-
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Panache.2ENext/with/529258261">Zulip</a></li>
681-
</ul>
682-
status: on track
683-
lts: false
684-
completed: false
685-
last-activity: 2025-10-17
686-
last-update-date: 2025-10-27
687-
last-update: |
688-
In the last month, the WG - Panache.Next did not close any issues but opened one to address the acceptance of `null` persistence units (PUs) in ORM and HR Panache. This highlights ongoing efforts to refine the next version of Panache, focusing on improving functionality and stability as the group progresses towards its development goals.
689-
690-
(This status update was automatically generated using AI.)
691-
point-of-contact: "@FroMage (@<strong>Stephane Epardaud</strong> on Zulip)"
692-
proposal: https://github.com/quarkusio/quarkus/discussions/48949
693-
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Panache.2ENext/with/529258261
694694
- title: "Quarkus 4"
695695
board-url: "https://github.com/orgs/quarkusio/projects/51"
696696
short-description: |

0 commit comments

Comments
 (0)