TLS is becoming increasingly common and recommended. However, for years, each Quarkus extension has been doing its own TLS configuration and management. As a result, the configuration looks different everywhere, and many extensions have incomplete configurations.
-Based on the newly integrated TLS registry, we now have a single place to configure TLS. At runtime, it provides methods to configure Vert.x and "pure" Java clients (using an SSLContext).
The 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: complete - last-activity: 2024-09-29 - last-update: | - This working group is complete! - That does not mean that no work will be done around TLS, but what was defined in the initial scope of the working group has been completed. - Enhancements and bug fixes will follow. - - title: "Quarkus to the CommonHaus Foundation" - board-url: "https://github.com/orgs/quarkusio/projects/38" - short-description: Work needed around moving Quarkus to foundation and streamline open governance. - readme: | -from Discussion at https://github.com/quarkusio/quarkus/discussions/43013
-We started the move of Quarkus to a foundation earlier this year and recently set the direction towards CommonHaus and during the summer break the CommonHaus council approved our request to join.
-Thus, now the real work starts, and it's just fitting we set up a working group for the effort getting Quarkus to CommonHaus foundation.
-Two parts
-Current known list, but not limited to:
-We will use the working group board to track publicly all the known relevant work and questions.For the few exception cases where, for legal or personal constraints, the work must happen in private, we will post the outcome and results in public places (like a GitHub discussion of a GitHub issue tracked on the working group board).
-When Quarkus has an active working governance model in place and all major work items around setting up Quarkus at CommonHaus are completed - after that, its expected things will just be iteratively improved, and the dedicated working group will not be needed (others might start to continue more specific efforts).
-The majority of the work must be done before the end of December 2024. The latest deadline for CommonHaus is April 2025, when the bootstrap period of CommonHaus ends.
- status: on track - last-activity: 2024-09-29 - last-update: | - Just got started. - - 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) - readme: | -This working group uses a different board:
-under discussion column contains the issues we would like to have in the next LTS but are still under consideration.out of scope column contains the issues under discussion' that won't be included. The reason can be time or technical...in progress means that the work has started and should be completed before the TLS cut datedone column means that the issues have been completedAt 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: 2024-09-24 - last-update: | - Since we don't have a target date, and progress is being made, I can declare this on track, with only a slightly murky conscience. - - This is a big change, and one which doesn't lend itself well to dividing into smaller chunks. I'm keeping a spreadsheet of build results. In the CI runs, the number of failing jobs was 31 at the last update, and it is now 25. A number of suites, such as `integration-tests/devtools` were failing, and are now passing. - - title: "Quarkus Config and IDEs" - board-url: "https://github.com/orgs/quarkusio/projects/32" - short-description: Let's define a format for the files containing the config model we will include in the jars for IDE consumption. - readme: | -Let's define a format for the files containing the config model we will include in the jars for IDE consumption.
-See https://github.com/quarkusio/quarkus/discussions/42671 for more details.
-Point of contact: @gsmet (Zulip: @_Guillaume Smet )
- status: on track - last-activity: 2024-09-24 - - title: "Roq :: Quarkus SSG" - board-url: "https://github.com/orgs/quarkiverse/projects/6" - short-description: Allow Static Site Generation with Quarkus. - readme: | -New initiative to allow Static Site Generation with Quarkus.
-Quarkus already provides most of the pieces to create great web applications (https://quarkus.io/guides/web).
-I recently added https://github.com/quarkiverse/quarkus-roq. It will allow generating a static website out of any Quarkus application (it starts the app, fetch all the configured pages and assets, generate a static website and stop), it already works but it is still very alpha.
-What's missing? we now need to incrementally add the toolkit to ease the process of creating static content through Quarkus:
-This will allow to develop the content using Quarkus dev-mode, and then generate for Github Pages or similar when it's ready.
-Bonus, everything added will benefit any "non-static" Quarkus app and any Static Quarkus app could also become non static.
-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: 2024-09-23 - last-update: | - 0.0.3 has been released, it is the MVP version and allowed to publish the Roq blog: https://quarkiverse.io/quarkus-roq/posts/2024-08-29-welcome-to-roq/ - - From now on, we start adding features incrementally, documenting. - - The target is to have 1.0.0 the 1 October 2024. - - For 1.0 we need pagination, tags and SEO. - - 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: on track - last-activity: 2024-09-05 - last-update: | - The last outstanding issue is OTel integration. @michalvavrik is working on a [pull request](https://github.com/quarkusio/quarkus/pull/41956). I will meet with Michal and Bruno in the coming weeks. The PR is quite massive and we need to review it carefully. + - title: "Enhanced TLS support" + board-url: "https://github.com/orgs/quarkusio/projects/24" + short-description: Track the progress around the new TLS configuration centralization and new features (like Let's Encrypt, Cert-Manager, and local experience...) + readme: | +TLS is becoming increasingly common and recommended. However, for years, each Quarkus extension has been doing its own TLS configuration and management. As a result, the configuration looks different everywhere, and many extensions have incomplete configurations.
+Based on the newly integrated TLS registry, we now have a single place to configure TLS. At runtime, it provides methods to configure Vert.x and "pure" Java clients (using an SSLContext).
The 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: complete + completed: true + last-activity: 2024-09-29 + last-update: | + This working group is complete! + That does not mean that no work will be done around TLS, but what was defined in the initial scope of the working group has been completed. + Enhancements and bug fixes will follow. + - title: "Quarkus to the CommonHaus Foundation" + board-url: "https://github.com/orgs/quarkusio/projects/38" + short-description: Work needed around moving Quarkus to foundation and streamline open governance. + readme: | +from Discussion at https://github.com/quarkusio/quarkus/discussions/43013
+We started the move of Quarkus to a foundation earlier this year and recently set the direction towards CommonHaus and during the summer break the CommonHaus council approved our request to join.
+Thus, now the real work starts, and it's just fitting we set up a working group for the effort getting Quarkus to CommonHaus foundation.
+Two parts
+Current known list, but not limited to:
+We will use the working group board to track publicly all the known relevant work and questions.For the few exception cases where, for legal or personal constraints, the work must happen in private, we will post the outcome and results in public places (like a GitHub discussion of a GitHub issue tracked on the working group board).
+When Quarkus has an active working governance model in place and all major work items around setting up Quarkus at CommonHaus are completed - after that, its expected things will just be iteratively improved, and the dedicated working group will not be needed (others might start to continue more specific efforts).
+The majority of the work must be done before the end of December 2024. The latest deadline for CommonHaus is April 2025, when the bootstrap period of CommonHaus ends.
+ status: on track + completed: false + last-activity: 2024-09-29 + last-update: | + Just got started. + - 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) + readme: | +This working group uses a different board:
+under discussion column contains the issues we would like to have in the next LTS but are still under consideration.out of scope column contains the issues under discussion' that won't be included. The reason can be time or technical...in progress means that the work has started and should be completed before the TLS cut datedone column means that the issues have been completedAt 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 + completed: false + last-activity: 2024-09-24 + last-update: | + Since we don't have a target date, and progress is being made, I can declare this on track, with only a slightly murky conscience. + + This is a big change, and one which doesn't lend itself well to dividing into smaller chunks. I'm keeping a spreadsheet of build results. In the CI runs, the number of failing jobs was 31 at the last update, and it is now 25. A number of suites, such as `integration-tests/devtools` were failing, and are now passing. + - title: "Quarkus Config and IDEs" + board-url: "https://github.com/orgs/quarkusio/projects/32" + short-description: Let's define a format for the files containing the config model we will include in the jars for IDE consumption. + readme: | +Let's define a format for the files containing the config model we will include in the jars for IDE consumption.
+See https://github.com/quarkusio/quarkus/discussions/42671 for more details.
+Point of contact: @gsmet (Zulip: @_Guillaume Smet )
+ status: on track + completed: false + last-activity: 2024-09-24 + - title: "Roq :: Quarkus SSG" + board-url: "https://github.com/orgs/quarkiverse/projects/6" + short-description: Allow Static Site Generation with Quarkus. + readme: | +New initiative to allow Static Site Generation with Quarkus.
+Quarkus already provides most of the pieces to create great web applications (https://quarkus.io/guides/web).
+I recently added https://github.com/quarkiverse/quarkus-roq. It will allow generating a static website out of any Quarkus application (it starts the app, fetch all the configured pages and assets, generate a static website and stop), it already works but it is still very alpha.
+What's missing? we now need to incrementally add the toolkit to ease the process of creating static content through Quarkus:
+This will allow to develop the content using Quarkus dev-mode, and then generate for Github Pages or similar when it's ready.
+Bonus, everything added will benefit any "non-static" Quarkus app and any Static Quarkus app could also become non static.
+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 + completed: false + last-activity: 2024-09-23 + last-update: | + 0.0.3 has been released, it is the MVP version and allowed to publish the Roq blog: https://quarkiverse.io/quarkus-roq/posts/2024-08-29-welcome-to-roq/ + + From now on, we start adding features incrementally, documenting. + + The target is to have 1.0.0 the 1 October 2024. + + For 1.0 we need pagination, tags and SEO. + - 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: on track + completed: false + last-activity: 2024-09-05 + last-update: | + The last outstanding issue is OTel integration. @michalvavrik is working on a [pull request](https://github.com/quarkusio/quarkus/pull/41956). I will meet with Michal and Bruno in the coming weeks. The PR is quite massive and we need to review it carefully. diff --git a/_includes/working-group-band.html b/_includes/working-group-band.html index ef6bc686264..da17bf2af2a 100644 --- a/_includes/working-group-band.html +++ b/_includes/working-group-band.html @@ -9,6 +9,7 @@ {% for item in site.data.wg.working-groups %} + {% unless item.completed %}{{ item.title }}
@@ -22,6 +23,24 @@ View the {{ item.title }} Board+ These working groups have completed their work and are no longer active: +
+