new dev ui section

add dev ui to the homepage add styling for section to the main.scss file images for section and potentially new page fix wording on single card and adjust card styling in general get the html to look somewhat decent. not done but its good enough for now new bare bone html page (nothing in it) dev ui page and its sections add border top to the section add new sections to the dev ui (config, kubernetes yaml, visualize endpoints) consolidate styling for new and existing sections fix wording on single card and adjust card styling in general get the html to look somewhat decent. not done but its good enough for now Sync documentation of main branch Sync working groups format dev ui page the way the other "why" pages are formatted Sync documentation of main branch fill out rest of the sections for dev ui page
quarkusio · Nov 29, 2024 · 17c7473 · 17c7473
1 parent a183769
commit 17c7473
Show file tree

Hide file tree

Showing 62 changed files with 1,606 additions and 3,854 deletions.
diff --git a/_data/wg.yaml b/_data/wg.yaml
@@ -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
@@ -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)