Skip to content

Commit

Permalink
Sync working groups
Browse files Browse the repository at this point in the history
  • Loading branch information
@actions-user
actions-user committed Nov 28, 2024
1 parent 7c850cc commit 8f7df2c
Showing 1 changed file with 28 additions and 28 deletions.
56 changes: 28 additions & 28 deletions _data/wg.yaml
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,33 @@
---
working-groups:
- title: "Test classloading"
board-url: "https://github.com/orgs/quarkusio/projects/30"
short-description: 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.
readme: |
<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>
<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>
<blockquote>
<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>
</blockquote>
<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>
<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>
<ul>
<li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li>
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/41867</li>
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/">Zulip topic</a></li>
</ul>
status: on track
completed: false
last-activity: 2024-11-28
last-update-date: 2024-11-25
last-update: |
Good progress in the past week. Latest CI run: https://github.com/holly-cummins/quarkus/actions/runs/11940609084
Down to 8 failing jobs on CI, which is, admittedly, awful, but it’s better than the 10 that were failing before this week. Fixed a bunch of problems in my implementation, some dumb (like typing ’text’ instead of ’test’, some more significant.)
The next task/blocker is @Nested tests which have a test profile. That means sorting out the contradiction between “load tests using the classloader we will use to execute them,” and “@Nested inner classes always get loaded by the parent’s classloader, which is totally the wrong classloader if there’s a @TestProfile on them”. I fear the solution may involve putting back a bunch of code I thought I was going to be able to delete.
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)"
proposal: https://github.com/quarkusio/quarkus/discussions/41867
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/
- title: "WebSocket Next"
board-url: "https://github.com/orgs/quarkusio/projects/26"
short-description: WebSocket-Next related tasks
Expand Down Expand Up @@ -76,34 +104,6 @@ working-groups:
deliverable: <a rel="nofollow" href="https://www.youtube.com/watch?v=VP7c9ftFwrQ">Quarkus Insight</a>
point-of-contact: "@cescoffier (@<strong>Clement Escoffier</strong> on Zulip)"
proposal: https://github.com/quarkusio/quarkus/discussions/41024
- title: "Test classloading"
board-url: "https://github.com/orgs/quarkusio/projects/30"
short-description: 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.
readme: |
<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>
<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>
<blockquote>
<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>
</blockquote>
<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>
<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>
<ul>
<li>Point of contact: @holly-cummins (@<strong>Holly Cummins</strong> on Zulip)</li>
<li>Proposal: https://github.com/quarkusio/quarkus/discussions/41867</li>
<li>Discussion: <a href="https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/">Zulip topic</a></li>
</ul>
status: on track
completed: false
last-activity: 2024-11-19
last-update-date: 2024-11-25
last-update: |
Good progress in the past week. Latest CI run: https://github.com/holly-cummins/quarkus/actions/runs/11940609084
Down to 8 failing jobs on CI, which is, admittedly, awful, but it’s better than the 10 that were failing before this week. Fixed a bunch of problems in my implementation, some dumb (like typing ’text’ instead of ’test’, some more significant.)
The next task/blocker is @Nested tests which have a test profile. That means sorting out the contradiction between “load tests using the classloader we will use to execute them,” and “@Nested inner classes always get loaded by the parent’s classloader, which is totally the wrong classloader if there’s a @TestProfile on them”. I fear the solution may involve putting back a bunch of code I thought I was going to be able to delete.
point-of-contact: "@holly-cummins (@<strong>Holly Cummins</strong> on Zulip)"
proposal: https://github.com/quarkusio/quarkus/discussions/41867
discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/
- title: "Quarkus 3.15 LTS"
board-url: "https://github.com/orgs/quarkusio/projects/28"
short-description: This WG focuses on defining the issues we would like to have in the next-to-be LTS (Quarkus 3.14/3.15)
Expand Down

0 comments on commit 8f7df2c

Please sign in to comment.