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 goal of this working group is to rewrite Quarkus's test classloading, so that tests are run in the same classloader as the application under tests, and Quarkus extensions can do "Quarkus-y" manipulations of test classes.
6
+
This working group aims to track the effort around the Quarkus 3.20 LTS version.
7
7
readme: |
8
-
<p>At the moment, Quarkus tests are invoked using one classloader, and then executed in a different classloader. This mostly works well, but means some use cases don't work: extensions cannot manipulate test classes in the same way that they do normal application classes. For example, anything run via a JUnit @TestTemplate test case will see the un-transformed class.</p>
9
-
<p>It also means we have extra user-facing complexity, such as the QuarkusTest*Callbacks](https://quarkus.io/guides/getting-started-testing#enrichment-via-quarkustestcallback):</p>
10
-
<blockquote>
11
-
<p>While it is possible to use JUnit Jupiter callback interfaces like BeforeEachCallback, you might run into classloading issues because Quarkus has to run tests in a custom classloader which JUnit is not aware of.</p>
12
-
</blockquote>
13
-
<p>A final benefit is a reduction in the internal complexity of our code. Hopping between classloaders during test execution takes a lot of work, and adds a lot of code! It also is brittle in places. For example, because the hop between classloaders relies on serialization in some cases, it's becoming harder to do as the JVM tightens up security restrictions. We used to rely on xstream, but that stopped working in Java 17. In https://github.com/quarkusio/quarkus/pull/40601, @dmlloyd moved us to use the JBoss Serializer, which works better, but might still be affected by future restrictions on class access.</p>
14
-
<p>The goal of this working group is to allow test classes to fully participate in the 'quarkification' of classes. The mechanism for this is probably just to load the test classes with the classloader we intend to run them with, so that JUnit sees the 'correct' version of the class.</p>
8
+
<p>All the tasks related to the 3.20 LTS, including issues with backport, release process, and so on.</p>
9
+
status: on track
10
+
lts: true
11
+
completed: false
12
+
last-activity: 2025-05-19
13
+
last-update-date: 2025-04-01
14
+
last-update: |
15
+
In the past month, the WG - Quarkus 3.20 LTS successfully closed three issues, addressing an exception related to missing Maven classes in the dev-ui for Gradle projects, enhancing the Grafana LGTM dashboards, and determining the appropriate Kafka client version for the 3.20 LTS release. No new issues were opened during this period, indicating focused progress on existing challenges.
<li>The <code>under discussion</code> column contains the issues we would like to have in the next LTS but are still under consideration.</li>
24
+
<li>The <code>out of scope</code> column contains the issues under discussion' that won't be included. The reason can be time or technical...</li>
25
+
<li>The <code>in progress</code> means that the work has started and should be completed before the TLS cut date</li>
26
+
<li>The <code>done</code> column means that the issues have been completed</li>
19
27
</ul>
20
28
status: on track
21
-
lts: false
29
+
lts: true
22
30
completed: false
23
31
last-activity: 2025-05-19
24
-
last-update-date: 2025-04-28
32
+
last-update-date: 2025-04-01
25
33
last-update: |
26
-
In the last month, the WG - Test classloading successfully closed significant issues related to classloader behavior, including fixing ServiceLoader errors and NullPointerExceptions that impacted test discovery. However, several issues were opened, focusing on recurring ServiceConfigurationErrors and additional classloader-related concerns. The team also initiated communications with the first blog detailing test classloading changes. This ongoing work aims to enhance Quarkus's test environment by ensuring proper classloader interactions and minimizing errors during testing.
27
-
28
-
(This status update was automatically generated using AI.)
29
-
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)"
In the last month, the WG - Quarkus 3.15 LTS closed two issues: one regarding the assignment of random ports in the configuration and another updating the Kafka client version to 3.7.2 to address CVE-2024-56128. No new issues were opened, reflecting a commitment to resolving important topics for the upcoming LTS release.
The goal of this working group is to rewrite Quarkus's test classloading, so that tests are run in the same classloader as the application under tests, and Quarkus extensions can do "Quarkus-y" manipulations of test classes.
64
+
readme: |
65
+
<p>At the moment, Quarkus tests are invoked using one classloader, and then executed in a different classloader. This mostly works well, but means some use cases don't work: extensions cannot manipulate test classes in the same way that they do normal application classes. For example, anything run via a JUnit @TestTemplate test case will see the un-transformed class.</p>
66
+
<p>It also means we have extra user-facing complexity, such as the QuarkusTest*Callbacks](https://quarkus.io/guides/getting-started-testing#enrichment-via-quarkustestcallback):</p>
67
+
<blockquote>
68
+
<p>While it is possible to use JUnit Jupiter callback interfaces like BeforeEachCallback, you might run into classloading issues because Quarkus has to run tests in a custom classloader which JUnit is not aware of.</p>
69
+
</blockquote>
70
+
<p>A final benefit is a reduction in the internal complexity of our code. Hopping between classloaders during test execution takes a lot of work, and adds a lot of code! It also is brittle in places. For example, because the hop between classloaders relies on serialization in some cases, it's becoming harder to do as the JVM tightens up security restrictions. We used to rely on xstream, but that stopped working in Java 17. In https://github.com/quarkusio/quarkus/pull/40601, @dmlloyd moved us to use the JBoss Serializer, which works better, but might still be affected by future restrictions on class access.</p>
71
+
<p>The goal of this working group is to allow test classes to fully participate in the 'quarkification' of classes. The mechanism for this is probably just to load the test classes with the classloader we intend to run them with, so that JUnit sees the 'correct' version of the class.</p>
72
+
<ul>
73
+
<li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li>
In the last month, the WG - Test classloading successfully closed significant issues related to classloader behavior, including fixing ServiceLoader errors and NullPointerExceptions that impacted test discovery. However, several issues were opened, focusing on recurring ServiceConfigurationErrors and additional classloader-related concerns. The team also initiated communications with the first blog detailing test classloading changes. This ongoing work aims to enhance Quarkus's test environment by ensuring proper classloader interactions and minimizing errors during testing.
84
+
85
+
(This status update was automatically generated using AI.)
86
+
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)"
This WG focuses on defining the issues we would like to have in the next-to-be LTS (Quarkus 3.14/3.15)
85
-
readme: |
86
-
<p>This working group uses a different board:</p>
87
-
<ul>
88
-
<li>The <code>under discussion</code> column contains the issues we would like to have in the next LTS but are still under consideration.</li>
89
-
<li>The <code>out of scope</code> column contains the issues under discussion' that won't be included. The reason can be time or technical...</li>
90
-
<li>The <code>in progress</code> means that the work has started and should be completed before the TLS cut date</li>
91
-
<li>The <code>done</code> column means that the issues have been completed</li>
92
-
</ul>
93
-
status: on track
94
-
lts: true
95
-
completed: false
96
-
last-activity: 2025-04-30
97
-
last-update-date: 2025-04-01
98
-
last-update: |
99
-
In the last month, the WG - Quarkus 3.15 LTS closed two issues: one regarding the assignment of random ports in the configuration and another updating the Kafka client version to 3.7.2 to address CVE-2024-56128. No new issues were opened, reflecting a commitment to resolving important topics for the upcoming LTS release.
This working group aims to track the effort around the Quarkus 3.20 LTS version.
104
-
readme: |
105
-
<p>All the tasks related to the 3.20 LTS, including issues with backport, release process, and so on.</p>
106
-
status: on track
107
-
lts: true
108
-
completed: false
109
-
last-activity: 2025-04-27
110
-
last-update-date: 2025-04-01
111
-
last-update: |
112
-
In the past month, the WG - Quarkus 3.20 LTS successfully closed three issues, addressing an exception related to missing Maven classes in the dev-ui for Gradle projects, enhancing the Grafana LGTM dashboards, and determining the appropriate Kafka client version for the 3.20 LTS release. No new issues were opened during this period, indicating focused progress on existing challenges.
0 commit comments