Sync documentation of main branch

Author: actions-user

_generated-doc/main/config/quarkus-all-config.adoc

@@ -148,7 +148,7 @@ If this is set to `warn` the application will warn at start up.
 
 If this is set to `fail` the application will fail at start up.
 
-Native tests leveraging`@io.quarkus.test.junit.TestProfile` are always run with `quarkus.configuration.build-time-mismatch-at-runtime = fail`.
+Native tests leveraging`@io.quarkus.test.junit.TestProfile` are always run with `quarkus.config.build-time-mismatch-at-runtime = fail`.
 
 
 ifdef::add-copy-button-to-env-var[]

_generated-doc/main/config/quarkus-core_quarkus.config.adoc

@@ -9,21 +9,21 @@ include::_attributes.adoc[]
 :summary: Trigger the inclusion on additional extensions based on certain conditions.
 :topics: extensions
 
-Quarkus extension dependencies are usually configured in the same way as any other project dependencies in the project's build file, e.g. the Maven `pom.xml` or the Gradle build scripts. However, there are dependency types that aren't yet supported out-of-the-box by Maven and Gradle. What we refer here to as "conditional dependencies" is one example.
+Quarkus extension dependencies are usually configured in the same way as any other project dependencies in a project's build file, e.g. the Maven `pom.xml` or the Gradle build scripts. However, Quarkus also supports types of dependencies that aren't supported out-of-the-box by Maven and Gradle. Conditional Quarkus extension dependencies falls into that category.
 
 == Conditional Dependencies
 
-The idea behind the notion of the conditional dependency is that such a dependency must be activated only if a certain condition is satisfied. If the condition is not satisfied then the dependency **must not** be activated. In that regard, conditional dependencies can be categorized as optional, i.e. they may or may not appear in the resulting set of project dependencies.
+A conditional dependency is a dependency that is activated only if a certain condition is satisfied. If the condition is not satisfied then the dependency **must not** be activated. In that regard, conditional dependencies can be categorized as optional, meaning they may or may not appear in the resulting dependency graph.
 
-In which cases could conditional dependencies be useful? A typical example would be a component that should be activated **only** in case all of its required dependencies are available. If one or more of the component's required dependencies aren't available, instead of failing, the component should simply not be activated.
+A typical example of a conditional dependency would be a component that should be added to the classpath **only** in case all of its required dependencies are present on the classpath. If one or more of the component's required dependencies aren't available, instead of failing, the component should simply not be added.
 
-== Quarkus Conditional Extension Dependencies
+== Conditional Quarkus Extension Dependencies
 
-Quarkus supports conditional extension dependencies. I.e. one Quarkus extension may declare one or more conditional dependencies on other Quarkus extensions. Conditional dependencies on and from non-extension artifacts aren't supported.
+A Quarkus extension may declare one or more conditional dependencies on other Quarkus extensions. Conditional dependencies on and from non-extension artifacts aren't supported.
 
-Let's take the following scenario as an example: `quarkus-extension-a` has an optional dependency on `quarkus-extension-b` which should be included in a Quarkus application only if `quarkus-extension-c` is found among its dependencies (direct or transitive). In other words, the presence of `quarkus-extension-c` is the condition which, if satisfied, enables `quarkus-extension-b` during the build of a Quarkus application.
+Let's consider the following scenario as an example: `quarkus-extension-a` has an optional dependency on `quarkus-extension-b` which should be included in a Quarkus application only if `quarkus-extension-c` is found among the application dependencies (direct or transitive). In this case, the presence of `quarkus-extension-c` is the condition which, if satisfied, will trigger inclusion of the `quarkus-extension-b` when Quarkus application dependencies are resolved.
 
-The condition which triggers activation of an extension is configured in the extension's descriptor, which is included into the runtime artifact of the extension as `META-INF/quarkus-extension.properties`. Given that extension descriptor is generated by the Quarkus plugin at extension build time, extension developers can add the following configuration to express the condition which would have to be satisfied for the extension to be activated:
+The condition which triggers activation of an extension is configured in the extension's `META-INF/quarkus-extension.properties`, which is included in the runtime artifact of the extension.Extension developers can add the following configuration to express the condition which would have to be satisfied for the extension to be activated:
 
 [source,xml]
 ----
@@ -61,20 +61,22 @@ The condition which triggers activation of an extension is configured in the ext
   <!-- SKIPPED CONTENT -->
 ----
 
-<1> runtime Quarkus extension artifact ID, in our example `quarkus-extension-b`;
+<1> runtime Quarkus extension artifact ID;
 <2> the goal that generates the extension descriptor which every Quarkus runtime extension project should be configured with;
-<3> configuration of the condition which will have to be satisfied for this extension to be included into a Quarkus application expressed as a list of artifacts that must be present among the application dependencies;
+<3> configuration of the dependency condition which will have to be satisfied for this extension to be added to a Quarkus application expressed as a list of artifacts that must be present among the application dependencies;
 <4> an artifact key (in the format of `groupId:artifactId[:<classifier>:<extension>]` but typically simply `<groupId>:<artifactId>`) of the artifact that must be present among the application dependencies for the condition to be satisfied.
 
-NOTE: In the example above the `artifact` used in the condition configuration happens to be a runtime Quarkus extension artifact but it could as well be any other artifact. There could also be more than one `artifact` element in the body of `dependencyCondition`.
+NOTE: In the example above the `artifact` used in the condition configuration happens to be a runtime Quarkus extension artifact but it could as well be any other artifact. There could also be more than one `artifact` element in the body of the `dependencyCondition`.
 
-Now, having a dependency activating condition in the descriptor of `quarkus-extension-b`, other extensions may declare a conditional dependency on it.
+Now, having a dependency condition recorded in the descriptor of the `quarkus-extension-b`, other extensions may declare a conditional dependency on it.
 
-A conditional dependency is configured in the runtime artifact of a Quarkus extension. In our example, it's the `quarkus-extension-a` that has a conditional dependency on `quarkus-extension-b`, which can be expressed in two ways.
+NOTE: extensions with dependency conditions present in their metadata could still appear as regular dependencies in Maven `pom.xml` and Gradle build scripts.
+
+A conditional dependency is configured in the runtime artifact of a Quarkus extension. In this example, the `quarkus-extension-a` will declare a conditional dependency on the `quarkus-extension-b`, which can be done in the following two ways.
 
 === Declaring a dependency as `optional`
 
-If an extension was configured with a dependency condition in its descriptor, other extensions may configure a conditional dependency on it by simply adding `<optional>true</optional>` to the dependency configuration. In our example it would look like this:
+If an extension includes a dependency condition in its descriptor, other extensions may configure a conditional dependency on it by simply adding `<optional>true</optional>` to the dependency configuration. In our example it would look like this:
 
 [source,xml]
 ----
@@ -101,7 +103,9 @@ If an extension was configured with a dependency condition in its descriptor, ot
 <1> the runtime extension artifact `quarkus-extension-a`
 <2> declares an optional Maven dependency on the runtime extension artifact `quarkus-extension-b`
 
-IMPORTANT: In general, for every runtime extension artifact dependency on another runtime extension artifact there must be a corresponding deployment extension artifact dependency on the other deployment extension artifact. And if the runtime dependency is declared as optional then the corresponding deployment dependency **must** also be configured as optional.
+Given that `quarkus-extension-b` includes a dependency condition, Quarkus will interpret an optional dependency on the `quarkus-extension-b` as conditional.
+
+IMPORTANT: In general, for every runtime extension artifact dependency on another runtime extension artifact there must be the corresponding deployment extension artifact dependency on the other deployment extension artifact. And if the runtime dependency is declared as optional then the corresponding deployment dependency **must** also be configured as optional.
 
 [source,xml]
 ----
@@ -128,13 +132,11 @@ IMPORTANT: In general, for every runtime extension artifact dependency on anothe
 <1> the deployment extension artifact `quarkus-extension-a-deployment`
 <2> declares an optional Maven dependency on the deployment extension artifact `quarkus-extension-b-deployment`
 
-Normally, optional Maven extension dependencies are ignored by the Quarkus dependency resolver at build time. In this case though, the optional dependency `quarkus-extension-b` includes a dependency condition in its extension descriptor, which turns this optional Maven dependency into a Quarkus conditional extension dependency.
-
-IMPORTANT: If `quarkus-extension-b` wasn't declared as `<optional>true</optional>` that would make `quarkus-extension-b` a required dependency of `quarkus-extension-a` and its dependency condition would be ignored.
+IMPORTANT: If the `quarkus-extension-b` dependency wasn't declared as `<optional>true</optional>` it would make the `quarkus-extension-b` a required dependency of the `quarkus-extension-a` and its dependency condition would be ignored by the application dependency resolver.
 
 === Declaring a conditional dependency in the Quarkus extension descriptor
 
-Conditional dependencies can also be configured in the Quarkus extension descriptor. The conditional dependency configured above could be expressed in the extension descriptor of `quarkus-extension-a` as:
+Conditional dependencies can also be configured in the Quarkus extension descriptor directly. Here is an example of how it can be done in the Quarkus extension plugin configuration of the `quarkus-extension-a`:
 
 [source,xml]
 ----
@@ -171,10 +173,61 @@ Conditional dependencies can also be configured in the Quarkus extension descrip
 
   <!-- SKIPPED CONTENT -->
 ----
+<1> the runtime Quarkus extension artifact ID;
+<2> the goal that generates the extension descriptor which every Quarkus runtime extension project should be configured with;
+<3> the conditional dependency configuration element;
+<4> the artifact coordinates of conditional dependencies on other extensions.
+
+In this case, the Maven dependency is not at all required in the `pom.xml` file.
+
+== Dev mode-only extension dependencies
+
+Extensions can also declare conditional dependencies on other extensions using Dev mode as the condition or one of the conditions for those dependencies to be activated.
+
+Dev mode-only extension dependencies can be configured in the Quarkus extension plugin in the following way:
+
+[source,xml]
+----
+<project xmlns="http://maven.apache.org/POM/4.0.0"
+         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+
+  <!-- SKIPPED CONTENT -->
+
+  <artifactId>quarkus-extension-a</artifactId> <1>
+
+  <!-- SKIPPED CONTENT -->
+
+  <build>
+    <plugins>
+      <plugin>
+        <groupId>io.quarkus</groupId>
+        <artifactId>quarkus-extension-maven-plugin</artifactId>
+        <version>${quarkus.version}</version>
+        <executions>
+          <execution>
+            <phase>process-resources</phase>
+            <goals>
+              <goal>extension-descriptor</goal> <2>
+            </goals>
+            <configuration>
+              <conditionalDevDependencies> <3>
+                <extension>org.acme:quarkus-extension-b:${b.version}</extension> <4>
+              </conditionalDevDependencies>
+            </configuration>
+          </execution>
+        </executions>
+      </plugin>
+
+  <!-- SKIPPED CONTENT -->
+----
+<1> the runtime Quarkus extension artifact ID;
+<2> the goal that generates the extension descriptor which every Quarkus runtime extension project should be configured with;
+<3> the Dev mode conditional dependency configuration element;
+<4> the artifact coordinates of conditional dependencies on extensions that should be evaluated only if an application is launched in Dev mode.
+
+The `quarkus-extension-b`, in this example, may or may not define its own condition to be evaluated.
 
-<1> runtime Quarkus extension artifact ID, in our example `quarkus-extension-a`
-<2> the goal that generates the extension descriptor which every Quarkus runtime extension project should be configured with
-<3> conditional dependency configuration element
-<4> artifact coordinates of conditional dependencies on other extensions.
+If the `quarkus-extension-b` does not define a dependency condition on its own (there is no dependency condition recorded in its `META-INF/quarkus-extension.properties`), the `quarkus-extension-b` will only be added as a dependency of the `quarkus-extension-a` in Dev mode but not in other modes (prod or test).
 
-In this case, the Maven dependency is not at all required in the `pom.xml`.
+If the `quarkus-extension-b` does define a dependency condition on its own (a dependency condition recorded in its `META-INF/quarkus-extension.properties`), the `quarkus-extension-b` will be added as a dependency of the `quarkus-extension-a` in Dev mode only if its condition is satisfied (the artifacts it requires are present in the application dependency graph).

_generated-doc/main/config/quarkus-oidc-client-registration.adoc

@@ -922,7 +922,7 @@ public JsonArray getAll() { // <2>
 <1> This example runs nonblocking. We could also return `Uni<JsonArray>`
 <2> The method name `getAll` will be available in the Javascript
 
-https://github.com/quarkusio/quarkus/blob/main/extensions/cache/runtime/src/main/java/io/quarkus/cache/runtime/devconsole/CacheJsonRPCService.java[Example code]
+https://github.com/quarkusio/quarkus/blob/main/extensions/cache/runtime/src/main/java/io/quarkus/cache/runtime/devui/CacheJsonRPCService.java[Example code]
 
 *Webcomponent (Javascript) part*
 

_generated-doc/main/config/quarkus-oidc-client-registration_quarkus.oidc-client-registration.adoc

@@ -10,11 +10,11 @@ include::_attributes.adoc[]
 :topics: templating,qute
 :extensions: io.quarkus:quarkus-qute,io.quarkus:quarkus-resteasy-qute,io.quarkus:quarkus-rest-qute
 
-Qute is a templating engine designed specifically to meet the Quarkus needs.
-The usage of reflection is minimized to reduce the size of native images.
+Qute is a templating engine developed specifically for Quarkus.
+Reflection usage is minimized to reduce the size of native images.
 The API combines both the imperative and the non-blocking reactive style of coding.
-In the development mode, all files located in `src/main/resources/templates` are watched for changes and modifications are immediately visible.
-Furthermore, we try to detect most of the template problems at build time.
+In development mode, all files located in `src/main/resources/templates` are monitored for changes, and modifications become visible immediately.
+Furthermore, we aim to detect most template issues at build time.
 In this guide, you will learn how to easily render templates in your application.
 
 == Solution
@@ -65,7 +65,7 @@ Let's start with a Hello World template:
 
 NOTE: Templates located in the `pub` directory are served via HTTP. This behavior is built-in, no controllers are needed. For example, the template `src/main/resources/templates/pub/foo.html` will be served from the paths `/foo` and `/foo.html` by default.
 
-If your application is running, you can open your browser and hit: http://localhost:8080/hello?name=Martin
+Once your application is running, you can open your browser and navigate to: http://localhost:8080/hello?name=Martin
 
 For more information about Qute Web options, see the https://docs.quarkiverse.io/quarkus-qute-web/dev/index.html[Qute Web guide].
 
@@ -144,7 +144,7 @@ Hello Martin!
 
 There's an alternate way to declare your templates in your Java code, which relies on the following convention:
 
-- Organise your template files in the `/src/main/resources/templates` directory, by grouping them into one directory per resource class. So, if
+- Organize your template files in the `/src/main/resources/templates` directory, by grouping them into one directory per resource class. So, if
   your `ItemResource` class references two templates `hello` and `goodbye`, place them at `/src/main/resources/templates/ItemResource/hello.txt`
   and `/src/main/resources/templates/ItemResource/goodbye.txt`. Grouping templates per resource class makes it easier to navigate to them.
 - In each of your resource class, declare a `@CheckedTemplate static class Template {}` class within your resource class.
@@ -389,7 +389,7 @@ public class ItemResource {
 *Template extension methods* are used to extend the set of accessible properties of data objects.
 
 Sometimes, you're not in control of the classes that you want to use in your template, and you cannot add methods
-to them. Template extension methods allows you to declare new method for those classes that will be available
+to them. Template extension methods allow you to declare new methods for those classes that will be available
 from your templates just as if they belonged to the target class.
 
 Let's keep extending on our simple HTML page that contains the item name, price and add a discounted price.
@@ -442,7 +442,7 @@ grouped by target type, or in a single `TemplateExtensions` class by convention.
 
 == Rendering Periodic Reports
 
-Templating engine could be also very useful when rendering periodic reports.
+The templating engine can also be very useful for rendering periodic reports.
 You'll need to add the `quarkus-scheduler` and `quarkus-qute` extensions first.
 In your `pom.xml` file, add: