|
1 | 1 | --- |
2 | 2 | working-groups: |
3 | | - - title: "Test classloading" |
4 | | - board-url: "https://github.com/orgs/quarkusio/projects/30" |
5 | | - short-description: | |
6 | | - 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. |
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> |
15 | | - <ul> |
16 | | - <li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li> |
17 | | - <li>Proposal: https://github.com/quarkusio/quarkus/discussions/41867</li> |
18 | | - <li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/">Zulip topic</a></li> |
19 | | - </ul> |
20 | | - status: staled |
21 | | - lts: false |
22 | | - completed: false |
23 | | - last-activity: 2025-08-30 |
24 | | - last-update-date: 2025-06-24 |
25 | | - last-update: | |
26 | | - In the last month, the WG - Test classloading successfully resolved multiple issues, including improvements to test executions in Quarkus 3.22, addressing classloader errors, and ensuring compatibility with various IDEs. However, several new issues were opened, focusing on logging behavior during tests, test ordering in multi-profile scenarios, and heap consumption changes in the transition to Quarkus 3.23. These discussions indicate ongoing efforts to refine the testing framework and enhance overall functionality. |
27 | | - |
28 | | - (This status update was automatically generated using AI.) |
29 | | - point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)" |
30 | | - proposal: https://github.com/quarkusio/quarkus/discussions/41867 |
31 | | - discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/ |
32 | | - - title: "Dev Services Lifecycle" |
33 | | - board-url: "https://github.com/orgs/quarkusio/projects/49" |
34 | | - short-description: | |
35 | | - This working group will define and implement a consistent and configurable lifecycle model for Dev Services. It will shift the startup to the correct phase, enable optional reuse across dev and test modes, and clarify teardown and sharing behavior. The goal is to improve the developer experience. |
36 | | - readme: | |
37 | | - <p>This working group was formed to address long-standing inconsistencies and pain points in the Dev Services lifecycle within Quarkus. Dev Services are essential for simplifying local development and testing by automatically provisioning runtime dependencies (e.g., databases, message brokers), but their current lifecycle behavior leads to confusion and inefficiencies. Most notably, they are started during the augmentation phase, which conflicts with their inherently runtime-oriented nature and causes issues with newer efforts such as the test classloading revamp.</p> |
38 | | - <p>The primary goal of this group is to define and implement a consistent, runtime-aligned lifecycle model for Dev Services. This includes shifting their startup to a phase after augmentation but before the application begins execution, ensuring better alignment with the runtime environment. A critical focus will also be on enabling optional reuse of Dev Services across dev and test modes — including reuse between repeated test executions — to reduce startup time and improve the iterative development experience.</p> |
39 | | - <p>The group's scope covers several strategic areas: formalizing when and how Dev Services are started, reused, or stopped; defining rules for discoverability and sharing between profiles or processes; and avoiding resource leaks or accidental retention. It explicitly excludes broader orchestration features (such as service dependency graphs) and unrelated feature enhancements.</p> |
40 | | - <p>The working group will produce a set of deliverables to support the new model. These include one or more Architecture Decision Records (ADRs) describing the new lifecycle model, the implementation of lifecycle logic in Quarkus Core, and updates to both user-facing and contributor documentation. Additionally, enhancements to the Dev Services development model will make it easier for extension authors to adopt and follow the new lifecycle standards. A public communication effort (e.g., blog posts or demos) will also be used to showcase the improvements.</p> |
41 | | - <ul> |
42 | | - <li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip), @ozangunalp (@<strong>Ozan Günalp</strong> on Zulip )</li> |
43 | | - <li>Proposal: https://github.com/quarkusio/quarkus/discussions/47683</li> |
44 | | - <li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev">Zulip</a>)</li> |
45 | | - </ul> |
46 | | - status: staled |
47 | | - lts: false |
48 | | - completed: false |
49 | | - last-activity: 2025-08-30 |
50 | | - last-update-date: 2025-06-24 |
51 | | - last-update: | |
52 | | - In the last month, the WG - Dev Services Lifecycle has made significant progress by closing several issues related to the Redis dev services, including enhancements in testing and controlling their startup behavior during augmentation. Additionally, new issues were opened to refine test coverage further and simplify the development services model, indicating ongoing efforts to enhance the developer experience and consistency. |
53 | | - |
54 | | - (This status update was automatically generated using AI.) |
55 | | - |
56 | | - |
57 | | - **NOTE**: The Redis exploration took a long time, but it has paved the way for the generalization for other dev services. Many test scenarios were not covered in the initial codebase. |
58 | | - point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip), @ozangunalp (@<strong>Ozan Günalp</strong> on Zulip )" |
59 | | - proposal: https://github.com/quarkusio/quarkus/discussions/47683 |
60 | | - discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev |
61 | 3 | - title: "Java 25 support" |
62 | 4 | board-url: "https://github.com/orgs/quarkusio/projects/59" |
63 | 5 | short-description: | |
@@ -122,13 +64,71 @@ working-groups: |
122 | 64 | status: on track |
123 | 65 | lts: false |
124 | 66 | completed: false |
125 | | - last-activity: 2025-08-28 |
| 67 | + last-activity: 2025-08-31 |
126 | 68 | last-update-date: 2025-08-27 |
127 | 69 | last-update: | |
128 | 70 | Working group started. |
129 | 71 | point-of-contact: "@Sanne (@<strong>Sanne</strong> on Zulip) and @gsmet (@_<strong>Guillaume Smet</strong> on Zulip)" |
130 | 72 | proposal: https://github.com/quarkusio/quarkus/discussions/49696 |
131 | 73 | discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20-.20Java.2025.20chat |
| 74 | + - title: "Test classloading" |
| 75 | + board-url: "https://github.com/orgs/quarkusio/projects/30" |
| 76 | + short-description: | |
| 77 | + 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. |
| 78 | + readme: | |
| 79 | + <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> |
| 80 | + <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> |
| 81 | + <blockquote> |
| 82 | + <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> |
| 83 | + </blockquote> |
| 84 | + <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> |
| 85 | + <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> |
| 86 | + <ul> |
| 87 | + <li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li> |
| 88 | + <li>Proposal: https://github.com/quarkusio/quarkus/discussions/41867</li> |
| 89 | + <li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/">Zulip topic</a></li> |
| 90 | + </ul> |
| 91 | + status: staled |
| 92 | + lts: false |
| 93 | + completed: false |
| 94 | + last-activity: 2025-08-30 |
| 95 | + last-update-date: 2025-06-24 |
| 96 | + last-update: | |
| 97 | + In the last month, the WG - Test classloading successfully resolved multiple issues, including improvements to test executions in Quarkus 3.22, addressing classloader errors, and ensuring compatibility with various IDEs. However, several new issues were opened, focusing on logging behavior during tests, test ordering in multi-profile scenarios, and heap consumption changes in the transition to Quarkus 3.23. These discussions indicate ongoing efforts to refine the testing framework and enhance overall functionality. |
| 98 | + |
| 99 | + (This status update was automatically generated using AI.) |
| 100 | + point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)" |
| 101 | + proposal: https://github.com/quarkusio/quarkus/discussions/41867 |
| 102 | + discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/ |
| 103 | + - title: "Dev Services Lifecycle" |
| 104 | + board-url: "https://github.com/orgs/quarkusio/projects/49" |
| 105 | + short-description: | |
| 106 | + This working group will define and implement a consistent and configurable lifecycle model for Dev Services. It will shift the startup to the correct phase, enable optional reuse across dev and test modes, and clarify teardown and sharing behavior. The goal is to improve the developer experience. |
| 107 | + readme: | |
| 108 | + <p>This working group was formed to address long-standing inconsistencies and pain points in the Dev Services lifecycle within Quarkus. Dev Services are essential for simplifying local development and testing by automatically provisioning runtime dependencies (e.g., databases, message brokers), but their current lifecycle behavior leads to confusion and inefficiencies. Most notably, they are started during the augmentation phase, which conflicts with their inherently runtime-oriented nature and causes issues with newer efforts such as the test classloading revamp.</p> |
| 109 | + <p>The primary goal of this group is to define and implement a consistent, runtime-aligned lifecycle model for Dev Services. This includes shifting their startup to a phase after augmentation but before the application begins execution, ensuring better alignment with the runtime environment. A critical focus will also be on enabling optional reuse of Dev Services across dev and test modes — including reuse between repeated test executions — to reduce startup time and improve the iterative development experience.</p> |
| 110 | + <p>The group's scope covers several strategic areas: formalizing when and how Dev Services are started, reused, or stopped; defining rules for discoverability and sharing between profiles or processes; and avoiding resource leaks or accidental retention. It explicitly excludes broader orchestration features (such as service dependency graphs) and unrelated feature enhancements.</p> |
| 111 | + <p>The working group will produce a set of deliverables to support the new model. These include one or more Architecture Decision Records (ADRs) describing the new lifecycle model, the implementation of lifecycle logic in Quarkus Core, and updates to both user-facing and contributor documentation. Additionally, enhancements to the Dev Services development model will make it easier for extension authors to adopt and follow the new lifecycle standards. A public communication effort (e.g., blog posts or demos) will also be used to showcase the improvements.</p> |
| 112 | + <ul> |
| 113 | + <li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip), @ozangunalp (@<strong>Ozan Günalp</strong> on Zulip )</li> |
| 114 | + <li>Proposal: https://github.com/quarkusio/quarkus/discussions/47683</li> |
| 115 | + <li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev">Zulip</a>)</li> |
| 116 | + </ul> |
| 117 | + status: staled |
| 118 | + lts: false |
| 119 | + completed: false |
| 120 | + last-activity: 2025-08-30 |
| 121 | + last-update-date: 2025-06-24 |
| 122 | + last-update: | |
| 123 | + In the last month, the WG - Dev Services Lifecycle has made significant progress by closing several issues related to the Redis dev services, including enhancements in testing and controlling their startup behavior during augmentation. Additionally, new issues were opened to refine test coverage further and simplify the development services model, indicating ongoing efforts to enhance the developer experience and consistency. |
| 124 | + |
| 125 | + (This status update was automatically generated using AI.) |
| 126 | + |
| 127 | + |
| 128 | + **NOTE**: The Redis exploration took a long time, but it has paved the way for the generalization for other dev services. Many test scenarios were not covered in the initial codebase. |
| 129 | + point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip), @ozangunalp (@<strong>Ozan Günalp</strong> on Zulip )" |
| 130 | + proposal: https://github.com/quarkusio/quarkus/discussions/47683 |
| 131 | + discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev |
132 | 132 | - title: "Gizmo 2" |
133 | 133 | board-url: "https://github.com/orgs/quarkusio/projects/43" |
134 | 134 | short-description: | |
|
0 commit comments