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
<p>This _working group aims to make the <a href="https://github.com/dmlloyd/gizmo/tree/gizmo2">Gizmo 2 POC</a> production-ready and integrate it into Quarkus core.</p>
9
-
<ul>
10
-
<li>Point of contact: @mkouba (@<strong>Martin Kouba</strong> on Zulip)</li>
In the past month, the WG - Gizmo 2 made notable progress by successfully closing several issues related to various technical enhancements and optimizations. Key improvements included fixing reversed body handling in `switch`, addressing caching for SAM locations, and reducing itable stub hits. The team also introduced new methods to streamline the handling of generic types and made efficiency improvements in `ExecutableCreatorImpl`. However, all the closed issues have also been reopened, indicating ongoing work and potential refinement needed for these tasks.
22
-
23
-
(This status update was automatically generated using AI.)
24
-
deliverable: TBD
25
-
point-of-contact: "@mkouba (@<strong>Martin Kouba</strong> on Zulip)"
In the past month, the WG - Dev Services Lifecycle made significant progress by closing essential issues related to the new dev services model. The team successfully transitioned AWS Lambda to the updated model, initiated services after augmentation, and added a runtime module for quarkus-devservices. However, a new issue was opened concerning the unintended startup of Keycloak dev services during the augmentation phase, along with another issue related to the QuarkusTestProfileAwareClassOrderer, indicating continued work needed to enhance the developer experience.
@@ -51,6 +26,60 @@ working-groups:
51
26
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip), @ozangunalp (@<strong>Ozan Günalp</strong> on Zulip )"
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.
33
+
readme: |
34
+
<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>
35
+
<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>
36
+
<blockquote>
37
+
<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>
38
+
</blockquote>
39
+
<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>
40
+
<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>
41
+
<ul>
42
+
<li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li>
In the last month, the WG - Test classloading achieved important milestones by successfully closing two issues related to test execution. They resolved problems with continuous testing failing in multi-module projects and addressed failures of QuarkusTests with nested classes in the IDEA IDE. However, a new issue was opened regarding the QuarkusTestProfileAwareClassOrderer, which no longer adheres to its expected contract, indicating ongoing challenges in refining the test classloading process.
53
+
54
+
(This status update was automatically generated using AI.)
55
+
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)"
<p>This _working group aims to make the <a href="https://github.com/dmlloyd/gizmo/tree/gizmo2">Gizmo 2 POC</a> production-ready and integrate it into Quarkus core.</p>
64
+
<ul>
65
+
<li>Point of contact: @mkouba (@<strong>Martin Kouba</strong> on Zulip)</li>
In the past month, the WG - Gizmo 2 made notable progress by successfully closing several issues related to various technical enhancements and optimizations. Key improvements included fixing reversed body handling in `switch`, addressing caching for SAM locations, and reducing itable stub hits. The team also introduced new methods to streamline the handling of generic types and made efficiency improvements in `ExecutableCreatorImpl`. However, all the closed issues have also been reopened, indicating ongoing work and potential refinement needed for these tasks.
77
+
78
+
(This status update was automatically generated using AI.)
79
+
deliverable: TBD
80
+
point-of-contact: "@mkouba (@<strong>Martin Kouba</strong> on Zulip)"
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.
444
-
readme: |
445
-
<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>
446
-
<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>
447
-
<blockquote>
448
-
<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>
449
-
</blockquote>
450
-
<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>
451
-
<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>
452
-
<ul>
453
-
<li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li>
In the last month, the WG - Test classloading achieved important milestones by successfully closing two issues related to test execution. They resolved problems with continuous testing failing in multi-module projects and addressed failures of QuarkusTests with nested classes in the IDEA IDE. However, a new issue was opened regarding the QuarkusTestProfileAwareClassOrderer, which no longer adheres to its expected contract, indicating ongoing challenges in refining the test classloading process.
464
-
465
-
(This status update was automatically generated using AI.)
466
-
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)"
0 commit comments