You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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&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>
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)"
In the last month, the WG - Java 25 support did not close any issues but opened a new issue focused on providing container images for Java 25. This activity aligns with the group's objective of ensuring Quarkus applications can run seamlessly across various modes on Java 25, without requiring it as a baseline.
@@ -140,6 +74,72 @@ working-groups:
140
74
point-of-contact: "@Sanne (@<strong>Sanne</strong> on Zulip) and @gsmet (@_<strong>Guillaume Smet</strong> on Zulip)"
The primary objective of this working group is to develop the next version of Panache.
81
+
readme: |
82
+
<h1>Objective</h1>
83
+
<p>The main objective of this working group is to bring forth the next version of Panache.</p>
84
+
<h1>The Problem</h1>
85
+
<p>Panache is great for many things, but over time, we realised the following limitations:</p>
86
+
<ul>
87
+
<li>We have three distinct versions: Hibernate ORM, Hibernate Reactive and Mongo (blocking and reactive)</li>
88
+
<li>It is impossible to use the same entities with Hibernate ORM and Hibernate Reactive</li>
89
+
<li>Stateless sessions are not supported</li>
90
+
<li>Hibernate Processor annotations, and Jakarta Data are not supported</li>
91
+
<li>We have triplicate types such as <code>Sort</code> and <code>Order</code> between Panache, ORM and Jakarta Data</li>
92
+
<li>We have two ways to place entity query operations : on the entity itself, or in repositories</li>
93
+
<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>
94
+
</ul>
95
+
<h1>The proposed Solution</h1>
96
+
<p>We propose a new Panache version that will solve all these issues:</p>
97
+
<ul>
98
+
<li>Unify all variants in a single module, supporting blocking, reactive, stateless and stateful sessions</li>
99
+
<li>Provide an entity toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
100
+
<li>Move all entity query operations from the entity class to the repository class</li>
101
+
<li>Provide a repository toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
102
+
<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>
103
+
<li>Provide out of the box accessors for the 4 modes of operation repositories on the entity metamodel class</li>
104
+
<li>Support Jakarta Data and Hibernate Processor type-safe annotations</li>
105
+
<li>Optional: Support of Mongo via the coming ORM JDBC support</li>
106
+
<li>Optional: provide JD repository type alternatives for the missing three modes</li>
107
+
<li>Optional: provide a way to convert Panache 1 to Panache.Next</li>
108
+
</ul>
109
+
<h1>Definition of Done</h1>
110
+
<ul>
111
+
<li>Deliver the new Panache extension as a <code>stable</code> state (after preview/experimental versions for feedback)</li>
112
+
<li>Tests</li>
113
+
<li>Documentation</li>
114
+
<li>Codestart</li>
115
+
<li>REST Data with Panache support</li>
116
+
<li>Renarde support</li>
117
+
<li>Quarkus Insights</li>
118
+
</ul>
119
+
<h1>Scope of Work</h1>
120
+
<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>
121
+
<h1>Organizing the Work</h1>
122
+
<h2>Communication and Transparency:</h2>
123
+
<p>This will be done via GitHub issues on the Quarkus core project.</p>
124
+
<h2>Expected Timeline:</h2>
125
+
<p>Most of the R&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>
126
+
<ul>
127
+
<li>Point of contact: @FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</li>
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.
138
+
139
+
(This status update was automatically generated using AI.)
140
+
point-of-contact: "@FroMage (@<strong>Stephane Epardaud</strong> on Zulip)"
0 commit comments