Merge branch 'quarkusio:main' into rest-client-response

.mvn/extensions.xml

@@ -17,6 +17,6 @@
     <extension>
         <groupId>io.quarkus.develocity</groupId>
         <artifactId>quarkus-project-develocity-extension</artifactId>
-        <version>1.1.8</version>
+        <version>1.1.9</version>
     </extension>
 </extensions>

bom/application/pom.xml

@@ -177,7 +177,7 @@
         <mockito.version>5.14.2</mockito.version>
         <jna.version>5.8.0</jna.version><!-- should satisfy both testcontainers and mongodb -->
         <quarkus-security.version>2.2.0</quarkus-security.version>
-        <keycloak.version>25.0.6</keycloak.version>
+        <keycloak-client.version>26.0.3</keycloak-client.version>
         <logstash-gelf.version>1.15.1</logstash-gelf.version>
         <checker-qual.version>3.48.3</checker-qual.version>
         <error-prone-annotations.version>2.36.0</error-prone-annotations.version>
@@ -6110,41 +6110,25 @@
                 <version>${quarkus-spring-boot-api.version}</version>
             </dependency>
 
-            <dependency>
-                <groupId>org.keycloak</groupId>
-                <artifactId>keycloak-core</artifactId>
-                <version>${keycloak.version}</version>
-            </dependency>
-            <dependency>
-                <groupId>org.keycloak</groupId>
-                <artifactId>keycloak-common</artifactId>
-                <version>${keycloak.version}</version>
-            </dependency>
             <dependency>
                 <groupId>org.keycloak</groupId>
                 <artifactId>keycloak-admin-client</artifactId>
-                <version>${keycloak.version}</version>
-                <exclusions>
-                    <exclusion>
-                        <groupId>org.checkerframework</groupId>
-                        <artifactId>checker-qual</artifactId>
-                    </exclusion>
-                </exclusions>
+                <version>${keycloak-client.version}</version>
             </dependency>
             <dependency>
                 <groupId>org.keycloak</groupId>
-                <artifactId>keycloak-adapter-spi</artifactId>
-                <version>${keycloak.version}</version>
+                <artifactId>keycloak-authz-client</artifactId>
+                <version>${keycloak-client.version}</version>
             </dependency>
             <dependency>
                 <groupId>org.keycloak</groupId>
-                <artifactId>keycloak-authz-client</artifactId>
-                <version>${keycloak.version}</version>
+                <artifactId>keycloak-policy-enforcer</artifactId>
+                <version>${keycloak-client.version}</version>
             </dependency>
             <dependency>
                 <groupId>org.keycloak</groupId>
-                <artifactId>keycloak-policy-enforcer</artifactId>
-                <version>${keycloak.version}</version>
+                <artifactId>keycloak-client-common-synced</artifactId>
+                <version>${keycloak-client.version}</version>
             </dependency>
             <dependency>
                 <groupId>io.quarkus</groupId>

build-parent/pom.xml

@@ -39,7 +39,7 @@
         <subethasmtp.version>6.0.1</subethasmtp.version>
 
         <!-- Dev tools -->
-        <freemarker.version>2.3.33</freemarker.version>
+        <freemarker.version>2.3.34</freemarker.version>
         <commonmark.version>0.24.0</commonmark.version>
 
         <!-- Arquillian BOM -->
@@ -95,10 +95,9 @@
         <junit4.version>4.13.2</junit4.version>
 
         <!-- The image to use for tests that run Keycloak -->
-        <!-- IMPORTANT: If this is changed you must also update bom/application/pom.xml and KeycloakBuildTimeConfig/DevServicesConfig in quarkus-oidc/deployment to match the version -->
-        <keycloak.version>25.0.6</keycloak.version>
+        <keycloak.server.version>25.0.6</keycloak.server.version>
         <keycloak.wildfly.version>19.0.3</keycloak.wildfly.version>
-        <keycloak.docker.image>quay.io/keycloak/keycloak:${keycloak.version}</keycloak.docker.image>
+        <keycloak.docker.image>quay.io/keycloak/keycloak:${keycloak.server.version}</keycloak.docker.image>
         <keycloak.docker.legacy.image>quay.io/keycloak/keycloak:${keycloak.wildfly.version}-legacy</keycloak.docker.legacy.image>
 
         <unboundid-ldap.version>7.0.2</unboundid-ldap.version>

docs/src/main/asciidoc/deploying-to-openshift.adoc

@@ -417,7 +417,7 @@ You can provide the arguments that will be used by the Kubernetes Job via the pr
 
 Finally, the Kubernetes job will be launched every time that is installed in OpenShift. You can know more about how to run Kubernetes jobs in this https://kubernetes.io/docs/concepts/workloads/controllers/job/#running-an-example-job[link].
 
-You can configure the rest of the Kubernetes Job configuration using the properties under `quarkus.openshift.job.xxx` (see xref:deploying-to-openshift#quarkus-kubernetes_quarkus-openshift-job-parallelism[link]).
+You can configure the rest of the Kubernetes Job configuration using the properties under `quarkus.openshift.job.xxx` (see xref:deploying-to-openshift.adoc#quarkus-kubernetes_quarkus-openshift-job-parallelism[link]).
 
 ===== Generating CronJob resources
 

docs/src/main/asciidoc/extension-maturity-matrix.adoc

@@ -27,7 +27,7 @@ It's completely OK to publish a first version of an extension that doesn't handl
 Also note that this list only includes the technical features of your extension.
 You might also want to think about how you share your extension, and how it presents itself to the world.
 The link:https://hub.quarkiverse.io/checklistfornewprojects/[new extension checklist] on the Quarkiverse Hub has a useful list of ways extensions can participate in the ecosystem.
-It's also a good idea to spend some time on the metadata in the xref:extension-metadata#quarkus-extension-yaml[`quarkus-extension.yaml` file], which is used by Quarkus tooling.
+It's also a good idea to spend some time on the metadata in the xref:extension-metadata.adoc#quarkus-extension-yaml[`quarkus-extension.yaml` file], which is used by Quarkus tooling.
 
 Here are some pointers on how to achieve those capabilities.
 
@@ -66,7 +66,7 @@ The Writing Extensions guide has more guidance on xref:writing-extensions.adoc#h
 === CDI Beans
 
 Quarkus extensions should aim to xref:writing-extensions.adoc#expose-your-components-via-cdi[expose components via CDI], so that they can be consumed in a frictionless way by user applications.
-Having everything injectable as CDI beans also helps testing, especially xref:getting-started-testing#mock-support[mocking].
+Having everything injectable as CDI beans also helps testing, especially xref:getting-started-testing.adoc#mock-support[mocking].
 
 === Dev Service
 
@@ -95,7 +95,7 @@ A good starting point is usually to use
 Although providing new, joyful, ways to do things is good,
 it's important to not break the normal patterns that users may be familiar with.
 
-For some inspiration in this area, have a look at xref:logging#simplified-logging[simplified logging], xref:hibernate-orm-panache.adoc[simplified Hibernate ORM with Panache], the xref:rest-client.adoc#query-parameters[`@RestQuery` annotation], or the way Quarkus allows test containers to be used xref:getting-started-dev-services.adoc[without any configuration].
+For some inspiration in this area, have a look at xref:logging.adoc#simplified-logging[simplified logging], xref:hibernate-orm-panache.adoc[simplified Hibernate ORM with Panache], the xref:rest-client.adoc#query-parameters[`@RestQuery` annotation], or the way Quarkus allows test containers to be used xref:getting-started-dev-services.adoc[without any configuration].
 
 === Codestart application template
 
@@ -124,7 +124,7 @@ For a case study of how to eliminate reflection and what the performance benefit
 === Virtual thread support
 
 Not every library is suitable for using with virtual threads, out of the box.
-xref:virtual-threads#why-not["Why not virtual threads everywhere?"] explains why.
+xref:virtual-threads.adoc#why-not["Why not virtual threads everywhere?"] explains why.
 
 To get your library working properly with virtual threads, you should make sure the library is not pinning the carrier thread.
  Quarkus has xref:virtual-threads.adoc#testing-virtual-thread-applications[test helpers to do these checks in an automated way].
@@ -157,7 +157,7 @@ Avoid using errors and warnings for conditions that will not affect normal opera
 
 === Define health endpoints
 
-Extensions may wish to xref:writing-extensions#extension-defined-endpoints[define library-specific endpoints] for health criteria which are specific to that extension. To add a new endpoint, extensions should produce a `NonApplicationRootPathBuildItem`.
+Extensions may wish to xref:writing-extensions.adoc#extension-defined-endpoints[define library-specific endpoints] for health criteria which are specific to that extension. To add a new endpoint, extensions should produce a `NonApplicationRootPathBuildItem`.
 
 === Tracing context
 
@@ -175,4 +175,4 @@ Being Kubernetes-native implies being container-native. At a minimum, extensions
 
 - xref:writing-extensions.adoc[Writing your own extension] guide
 - xref:building-my-first-extension.adoc[Building your first extension]
-- link:https://hub.quarkiverse.io.adoc[The Quarkiverse Hub documentation]
+- link:https://hub.quarkiverse.io.adoc[The Quarkiverse Hub documentation]

docs/src/main/asciidoc/getting-started-testing.adoc

@@ -1224,20 +1224,20 @@ public @interface WithRepeatableTestResource {
 }
 ----
 
-=== Usage of `@WithTestResources`
+=== Usage of `@WithTestResource`
 
-While test resources provided by `@QuarkusTestResource` are available either globally or restricted to the annotated test class (`restrictToAnnotatedClass`), the annotation `@WithTestResources` allows to additionally group tests by test resources for execution.
-`@WithTestResources` has a `scope` property that takes a `TestResourceScope` enum value:
+While test resources provided by `@QuarkusTestResource` are available either globally or restricted to the annotated test class (`restrictToAnnotatedClass`), the annotation `@WithTestResource` allows to additionally group tests by test resources for execution.
+`@WithTestResource` has a `scope` property that takes a `TestResourceScope` enum value:
 
 - `TestResourceScope.MATCHING_RESOURCES` (default): Quarkus will group tests with the same test resources and run them together. After a group has been executed, all test resources will be stopped, and the next group will be executed.
 - `TestResourceScope.RESTRICTED_TO_CLASS`: The test resource is available only for the annotated test class and will be stopped after the test class has been executed.
-- `TestResourceScope.GLOBAL`: Test resources apply to all tests in the testsuite
+- `TestResourceScope.GLOBAL`: Test resources apply to all tests in the test suite
 
 Quarkus needs to restart if one of the following is true:
 
-- At least one the existing test resources is restricted to the test class
-- At least one the next test resources is restricted to the test class
-- Different {@code MATCHING_RESOURCE} scoped test resources are being used
+- At least one of the test resources of the current test is restricted to the test class
+- At least one of the test resources of the next test is restricted to the test class
+- Different `MATCHING_RESOURCES` scoped test resources are being used
 
 == Hang Detection
 

docs/src/main/asciidoc/security-oidc-auth0-tutorial.adoc

@@ -928,7 +928,7 @@ Press `r` and notice this test failing with `403` which is expected because the
 
 image::auth0-test-failure-403.png[Auth0 test failure 403]
 
-Before fixing the test, let's review the options available for testing Quarkus endpoints secured by OIDC. These options might vary, depending on which flow your application supports and how you prefer to test. Endpoints which use OIDC authorization code flow can be tested using xref:security-oidc-code-flow-authentication#code-flow-integration-testing[one of these options] and endpoints which use Bearer token authentication can be tested using xref:security-oidc-bearer-token-authentication#bearer-token-integration-testing[one of these options].
+Before fixing the test, let's review the options available for testing Quarkus endpoints secured by OIDC. These options might vary, depending on which flow your application supports and how you prefer to test. Endpoints which use OIDC authorization code flow can be tested using xref:security-oidc-code-flow-authentication.adoc#code-flow-integration-testing[one of these options] and endpoints which use Bearer token authentication can be tested using xref:security-oidc-bearer-token-authentication.adoc#bearer-token-integration-testing[one of these options].
 
 As you can see, testing of the endpoints secured with Auth0 can be done with the help of `Wiremock`, or `@TestSecurity` annotation. Experiment with writing such tests on your own and reach out if you encounter any problems.
 
@@ -956,7 +956,7 @@ image::auth0-password-grant.png[Auth0 password grant]
 It is important to clarify that we do not recommend using the deprecated OAuth2 `password` token grant in production. However using it can help testing the endpoint with tokens acquired from the live dev Auth0 tenant.
 ====
 
-`OidcTestClient` should be used to test applications accepting bearer tokens which will work for the endpoint developed in this tutorial as it supports both authorization code flow and bearer token authentication. You would need to use OIDC WireMock or `HtmlUnit` directly against the Auth0 dev tenant if only the authorization code flow was supported - in the latter case `HtmlUnit` test code would have to be aligned with how Auth0 challenges users to enter their credentials. If you like, you can copy the xref:security-oidc-code-flow-authentication#code-flow-integration-testing-wiremock[HtmlUnit test fragment] from the documentation and experiment with it.
+`OidcTestClient` should be used to test applications accepting bearer tokens which will work for the endpoint developed in this tutorial as it supports both authorization code flow and bearer token authentication. You would need to use OIDC WireMock or `HtmlUnit` directly against the Auth0 dev tenant if only the authorization code flow was supported - in the latter case `HtmlUnit` test code would have to be aligned with how Auth0 challenges users to enter their credentials. If you like, you can copy the xref:security-oidc-code-flow-authentication.adoc#code-flow-integration-testing-wiremock[HtmlUnit test fragment] from the documentation and experiment with it.
 
 In meantime we will now proceed with fixing the currently failing test using `OidcTestClient`.
 

docs/src/main/asciidoc/security-oidc-bearer-token-authentication.adoc

@@ -1280,7 +1280,7 @@ quarkus.tls.oidc-server-mtls.trust-store.p12.password=password
 
 The above configuration is sufficient to require that OIDC bearer tokens are bound to the client certificates.
 
-Next, if you need to access both mTLS and OIDC bearer security identities, consider enabling xref:security-authentication-mechanisms#combining-authentication-mechanisms[Inclusive authentication] with `quarkus.http.auth.inclusive=true`.
+Next, if you need to access both mTLS and OIDC bearer security identities, consider enabling xref:security-authentication-mechanisms.adoc#combining-authentication-mechanisms[Inclusive authentication] with `quarkus.http.auth.inclusive=true`.
 
 Now you can access both MTLS and OIDC security identities as follows:
 
@@ -1419,7 +1419,7 @@ Authentication that requires a dynamic tenant will fail.
 == OIDC request filters
 
 You can filter OIDC requests made by Quarkus to the OIDC provider by registering one or more `OidcRequestFilter` implementations, which can update or add new request headers, and log requests.
-For more information, see xref:security-oidc-code-flow-authentication#code-flow-oidc-request-filters[OIDC request filters].
+For more information, see xref:security-oidc-code-flow-authentication.adoc#code-flow-oidc-request-filters[OIDC request filters].
 
 [[bearer-token-oidc-response-filters]]
 === OIDC response filters

docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc

@@ -300,7 +300,7 @@ quarkus.tls.oidc.trust-store.p12.password=${trust-store-password}
 
 ==== POST query
 
-Some providers, such as the xref:security-openid-connect-providers#strava[Strava OAuth2 provider], require client credentials be posted as HTTP POST query parameters:
+Some providers, such as the xref:security-openid-connect-providers.adoc#strava[Strava OAuth2 provider], require client credentials be posted as HTTP POST query parameters:
 
 [source,properties]
 ----
@@ -416,7 +416,7 @@ import io.quarkus.oidc.runtime.OidcUtils;
 @Unremovable
 @OidcEndpoint(value = Type.TOKEN) <1>
 public class TokenEndpointResponseFilter implements OidcResponseFilter {
-    
+
     @Override
     public void filter(OidcResponseContext rc) {
         String contentType = rc.responseHeaders().get("Content-Type"); <2>
@@ -1853,7 +1853,7 @@ To import a custom realm file into Keycloak before running the tests, configure
 quarkus.keycloak.devservices.realm-path=quarkus-realm.json
 ----
 
-Finally, write the test code as described in the <<code-flow-integration-testing-wiremock,Wiremock>> section.  
+Finally, write the test code as described in the <<code-flow-integration-testing-wiremock,Wiremock>> section.
 The only difference is that `@QuarkusTestResource` is no longer required:
 
 [source, java]