The WebSocket Next focus group aims to improve our WebSocket experience.
-Recently, we delivered a new approach to dealing with WebSocket (both for the server and client). This was the first step. There are still a few areas to improve, such as documentation, security, observability, and testability. The goal of this focus group is to track these efforts.
-Point of contact: @mkouba (@Martin Kouba on Zulip)
- status: on track - last-activity: "July 12, 2024" - 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) @@ -21,7 +12,7 @@ working-groups:done column means that the issues have been completedThe goal of this focus group is to continue integrating the TLS registry and improve Quarkus integration with certificate providers (Let's Encrypt, Cert-Manager). In addition, we would like to provide a frictionless local experience around TLS (i.e., without the infamous untrusted certificate screen).
Point of contact: @cescoffier (@Clement Escoffier on Zulip)
status: on track - last-activity: "July 9, 2024" - - title: "Docker file generation" - board-url: "https://github.com/orgs/quarkusio/projects/27" - short-description: A working group focusing on the generation of Dockerfile / ContainerFile + last-activity: 19/08/2024 + last-update: We just got an end-to-end let's encrypt demo working! + - 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: | -At the moment, when you create a Quarkus project (from code.quarkus.io or the CLI), a set of Dockerfiles is generated. However,
This working group aims to replace these `Dockerfiles' with a CLI command that generates an up-to-date Dockerfile and includes extension customization.
-The goal is not to allow updating these files once generated but to provide a one-off generation that the user can consult and use. It will use the recommended and up-to-date FROM image to improve security and, depending on the generated variant (JVM, native, native-micro...), follow good practices (such as using run-java for the JVM one).
You can find more details about this working group on this discussion. - Once completed, this working group will be followed by other initiatives focusing on generating the Github Action and Tekton pipelines.
-Point of contact: @iocanel (Ioannis Canelloson Zulip)
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.
+It also means we have extra user-facing complexity, such as the QuarkusTest*Callbacks](https://quarkus.io/guides/getting-started-testing#enrichment-via-quarkustestcallback):
+++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.
+
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.
+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.
status: on track - last-activity: "July 9, 2024" + last-activity: 18/08/2024 - title: "Roq :: Quarkus SSG" board-url: "https://github.com/orgs/quarkiverse/projects/6" short-description: Allow Static Site Generation with Quarkus. @@ -69,5 +57,31 @@ working-groups:This effort is now tracked using a "Working Group" project: https://github.com/orgs/quarkiverse/projects/6
This is a great opportunity to participate in fun effort and be involved with the Quarkus community, if anyone is interested in being a part of this, please reach out to me 🚀
status: on track - last-activity: "July 8, 2024" + last-activity: 16/08/2024 last-update: Good progress so far. + - title: "Docker file generation" + board-url: "https://github.com/orgs/quarkusio/projects/27" + short-description: A working group focusing on the generation of Dockerfile / ContainerFile + readme: | +At the moment, when you create a Quarkus project (from code.quarkus.io or the CLI), a set of Dockerfiles is generated. However,
This working group aims to replace these `Dockerfiles' with a CLI command that generates an up-to-date Dockerfile and includes extension customization.
+The goal is not to allow updating these files once generated but to provide a one-off generation that the user can consult and use. It will use the recommended and up-to-date FROM image to improve security and, depending on the generated variant (JVM, native, native-micro...), follow good practices (such as using run-java for the JVM one).
You can find more details about this working group on this discussion. + Once completed, this working group will be followed by other initiatives focusing on generating the Github Action and Tekton pipelines.
+Point of contact: @iocanel (Ioannis Canelloson Zulip)
The WebSocket Next focus group aims to improve our WebSocket experience.
+Recently, we delivered a new approach to dealing with WebSocket (both for the server and client). This was the first step. There are still a few areas to improve, such as documentation, security, observability, and testability. The goal of this focus group is to track these efforts.
+Point of contact: @mkouba (@Martin Kouba on Zulip)
+ status: staled + last-activity: 24/07/2024