This _working group aims to make the Gizmo 2 POC production-ready and integrate it into Quarkus core.
The goal of this working group is to improve quarkus-oidc by: implementing crucial new security features, continuing with improving the way OIDC requests can be intercepted, prioritizing some other open issues, such as using JWT bearer client authentication to complete the authorization code flow
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):
@@ -65,7 +68,8 @@ working-groups: discussion: https://quarkusio.zulipchat.com/#narrow/channel/187038-dev/topic/WG.20.2330.20Test.20Classloading.20chatter/ - title: "Quarkus 3.20 LTS" board-url: "https://github.com/orgs/quarkusio/projects/41" - short-description: This working group aims to track the effort around the Quarkus 3.20 LTS version. + short-description: | + This working group aims to track the effort around the Quarkus 3.20 LTS version. readme: |All the tasks related to the 3.20 LTS, including issues with backport, release process, and so on.
status: staled @@ -76,7 +80,8 @@ working-groups: Starting tracking tasks fro the 3.19 LTS. - 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) + 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:
The main objective of this working group is to allow AI features in Quarkus Dev Mode (Dev UI and CLI)
Observability.Next is a strategic initiative to modernize the observability stack within the Quarkus framework, aiming to streamline and enhance its ability to monitor and manage distributed systems. Currently, Quarkus (3.16.x) leverages the following components for observability: @@ -197,7 +204,8 @@ working-groups: proposal: https://github.com/quarkusio/quarkus/discussions/44423 - title: "WebSocket Next" board-url: "https://github.com/orgs/quarkusio/projects/26" - short-description: WebSocket-Next related tasks + short-description: | + WebSocket-Next related tasks readme: |
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.
@@ -218,7 +226,8 @@ working-groups: proposal: https://github.com/quarkusio/quarkus/discussions/38473 - 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. + 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.
@@ -231,7 +240,8 @@ working-groups: I fixed a few issues in the doc generation but wasn't able to make much progress for this round. - title: "Roq :: Quarkus SSG" board-url: "https://github.com/orgs/quarkiverse/projects/6" - short-description: Allow Static Site Generation with Quarkus. + 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).
@@ -264,7 +274,8 @@ working-groups: proposal: https://github.com/quarkusio/quarkus/discussions/41309 - 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...) + 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).
At the moment, when you create a Quarkus project (from code.quarkus.io or the CLI), a set of Dockerfiles is generated. However,
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.
diff --git a/working-groups/templates/wg.yaml.template b/working-groups/templates/wg.yaml.template index dad4f19a7e6..fa276136c8a 100644 --- a/working-groups/templates/wg.yaml.template +++ b/working-groups/templates/wg.yaml.template @@ -3,7 +3,8 @@ working-groups: {#for board in boards} - title: "{board.title}" board-url: "{board.url}" - short-description: "{board.shortDescription.trim()}" + short-description: | + {board.shortDescription.trim()} readme: | {board.getIndentedReadme().raw} status: {board.getBadgeText()}