Fix headers and preambles in all guides and reintroduce some keywords

docs/src/main/asciidoc/ansible.adoc

@@ -1,3 +1,8 @@
+////
+This guide is maintained in the main Quarkus repository
+and pull requests should be submitted there:
+https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
+////
 = Automate Quarkus deployment with Ansible
 include::_attributes.adoc[]
 :categories: command-line

docs/src/main/asciidoc/cdi-reference.adoc

@@ -6,6 +6,7 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 = Contexts and Dependency Injection
 include::_attributes.adoc[]
 :categories: core
+:keywords: arc
 :summary: Go more in depth into the Quarkus implementation of CDI.
 :numbered:
 :sectnums:

docs/src/main/asciidoc/cdi.adoc

@@ -6,6 +6,7 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 = Introduction to Contexts and Dependency Injection (CDI)
 include::_attributes.adoc[]
 :categories: core
+:keywords: qualifier event interceptor observer arc
 :summary: Quarkus DI solution is based on the [Jakarta Contexts and Dependency Injection 4.0](https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html) specification. This guide explains the basics of CDI.
 :numbered:
 :sectnums:
@@ -28,7 +29,7 @@ It creates and destroys the instances of beans, associates the instances with a
 
 An application developer can focus on the business logic rather than finding out "where and how" to obtain a fully initialized component with all of its dependencies.
 
-NOTE: You've probably heard of the _inversion of control_ (IoC) programming principle. Dependency injection is one of the implementation techniques of IoC. 
+NOTE: You've probably heard of the _inversion of control_ (IoC) programming principle. Dependency injection is one of the implementation techniques of IoC.
 
 == What does a bean look like?
 
@@ -47,9 +48,9 @@ public class Translator {
 
     @Inject
     Dictionary dictionary; <2>
-    
+
     @Counted  <3>
-    String translate(String sentence) { 
+    String translate(String sentence) {
       // ...
     }
 }
@@ -86,8 +87,8 @@ public class Translator {
 
     @Inject
     Instance<Dictionary> dictionaries; <1>
-    
-    String translate(String sentence) { 
+
+    String translate(String sentence) {
       for (Dictionary dict : dictionaries) { <2>
          // ...
       }
@@ -122,11 +123,11 @@ public class Translator {
     }
 }
 ----
-<1> This is a constructor injection. 
-In fact, this code would not work in regular CDI implementations where a bean with a normal scope must always declare a no-args constructor and the bean constructor must be annotated with `@Inject`. 
+<1> This is a constructor injection.
+In fact, this code would not work in regular CDI implementations where a bean with a normal scope must always declare a no-args constructor and the bean constructor must be annotated with `@Inject`.
 However, in Quarkus we detect the absence of no-args constructor and "add" it directly in the bytecode.
 It's also not necessary to add `@Inject` if there is only one constructor present.
-<2> An initializer method must be annotated with `@Inject`. 
+<2> An initializer method must be annotated with `@Inject`.
 <3> An initializer may accept multiple parameters - each one is an injection point.
 
 == You talked about some qualifiers?
@@ -155,7 +156,7 @@ The qualifiers of a bean are declared by annotating the bean class or producer m
 @ApplicationScoped
 public class SuperiorTranslator extends Translator {
 
-    String translate(String sentence) { 
+    String translate(String sentence) {
       // ...
     }
 }
@@ -180,11 +181,11 @@ You can use all the built-in scopes mentioned by the specification except for `j
 
 [options="header",cols="1,1"]
 |===
-|Annotation   |Description   
+|Annotation   |Description
 //----------------------
-|`@jakarta.enterprise.context.ApplicationScoped`   | A single bean instance is used for the application and shared among all injection points. The instance is created lazily, i.e. once a method is invoked upon the <<client_proxies, client proxy>>. 
+|`@jakarta.enterprise.context.ApplicationScoped`   | A single bean instance is used for the application and shared among all injection points. The instance is created lazily, i.e. once a method is invoked upon the <<client_proxies, client proxy>>.
 |`@jakarta.inject.Singleton`   | Just like `@ApplicationScoped` except that no client proxy is used. The instance is created when an injection point that resolves to a @Singleton bean is being injected.
-|`@jakarta.enterprise.context.RequestScoped`   | The bean instance is associated with the current _request_ (usually an HTTP request). 
+|`@jakarta.enterprise.context.RequestScoped`   | The bean instance is associated with the current _request_ (usually an HTTP request).
 |`@jakarta.enterprise.context.Dependent`   | This is a pseudo-scope. The instances are not shared and every injection point spawns a new instance of the dependent bean. The lifecycle of dependent bean is bound to the bean injecting it - it will be created and destroyed along with the bean injecting it.
 |`@jakarta.enterprise.context.SessionScoped`   | This scope is backed by a `jakarta.servlet.http.HttpSession` object. It's only available if the `quarkus-undertow` extension is used.
 |===
@@ -217,23 +218,23 @@ Indeed, the https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#
 A client proxy is basically an object that delegates all method invocations to a target bean instance.
 It's a container construct that implements `io.quarkus.arc.ClientProxy` and extends the bean class.
 
-IMPORTANT: Client proxies only delegate method invocations. So never read or write a field of a normal scoped bean, otherwise you will work with non-contextual or stale data. 
+IMPORTANT: Client proxies only delegate method invocations. So never read or write a field of a normal scoped bean, otherwise you will work with non-contextual or stale data.
 
 .Generated Client Proxy Example
 [source,java]
 ----
 @ApplicationScoped
 class Translator {
 
-    String translate(String sentence) { 
+    String translate(String sentence) {
       // ...
     }
 }
 
 // The client proxy class is generated and looks like...
 class Translator_ClientProxy extends Translator { <1>
 
-    String translate(String sentence) { 
+    String translate(String sentence) {
       // Find the correct translator instance...
       Translator translator = getTranslatorInstanceFromTheApplicationContext();
       // And delegate the method invocation...
@@ -247,10 +248,10 @@ Client proxies allow for:
 
 * Lazy instantiation - the instance is created once a method is invoked upon the proxy.
 * Ability to inject a bean with "narrower" scope to a bean with "wider" scope; i.e. you can inject a `@RequestScoped` bean into an `@ApplicationScoped` bean.
-* Circular dependencies in the dependency graph. Having circular dependencies is often an indication that a redesign should be considered, but sometimes it's inevitable. 
+* Circular dependencies in the dependency graph. Having circular dependencies is often an indication that a redesign should be considered, but sometimes it's inevitable.
 * In rare cases it's practical to destroy the beans manually. A direct injected reference would lead to a stale bean instance.
- 
- 
+
+
 == OK. You said that there are several kinds of beans?
 
 Yes. In general, we distinguish:
@@ -273,7 +274,7 @@ public class Producers {
 
     @Produces <1>
     double pi = Math.PI; <2>
-    
+
     @Produces <3>
     List<String> names() {
        List<String> names = new ArrayList<>();
@@ -289,26 +290,26 @@ public class Consumer {
 
    @Inject
    double pi;
-   
+
    @Inject
    List<String> names;
-   
-   // ...   
-} 
+
+   // ...
+}
 ----
 <1> The container analyses the field annotations to build a bean metadata.
-The _type_ is used to build the set of bean types. 
+The _type_ is used to build the set of bean types.
 In this case, it will be `double` and `java.lang.Object`.
 No scope annotation is declared and so it's defaulted to `@Dependent`.
 <2> The container will read this field when creating the bean instance.
 <3> The container analyses the method annotations to build a bean metadata.
-The _return type_ is used to build the set of bean types. 
+The _return type_ is used to build the set of bean types.
 In this case, it will be `List<String>`, `Collection<String>`, `Iterable<String>` and `java.lang.Object`.
 No scope annotation is declared and so it's defaulted to `@Dependent`.
 <4> The container will call this method when creating the bean instance.
 
-There's more about producers. 
-You can declare qualifiers, inject dependencies into the producer methods parameters, etc. 
+There's more about producers.
+You can declare qualifiers, inject dependencies into the producer methods parameters, etc.
 You can read more about producers for example in the https://docs.jboss.org/weld/reference/latest/en-US/html/producermethods.html[Weld docs, window="_blank"].
 
 == OK, injection looks cool. What other services are provided?
@@ -330,7 +331,7 @@ public class Translator {
     void init() {
        // ...
     }
-    
+
     @PreDestroy <2>
     void destroy() {
       // ...
@@ -345,7 +346,7 @@ TIP: It's a good practice to keep the logic in the callbacks "without side effec
 [[interceptors]]
 === Interceptors
 
-Interceptors are used to separate cross-cutting concerns from business logic. 
+Interceptors are used to separate cross-cutting concerns from business logic.
 There is a separate specification - Java Interceptors - that defines the basic programming model and semantics.
 
 .Simple Interceptor Binding Example
@@ -392,11 +393,11 @@ public class LoggingInterceptor {
       // ...log after
       return ret;
    }
-    
+
 }
 ----
 <1> The interceptor binding annotation is used to bind our interceptor to a bean. Simply annotate a bean class with `@Logged`, as in the following example.
-<2> `Priority` enables the interceptor and affects the interceptor ordering. Interceptors with smaller priority values are called first. 
+<2> `Priority` enables the interceptor and affects the interceptor ordering. Interceptors with smaller priority values are called first.
 <3> Marks an interceptor component.
 <4> An interceptor may inject dependencies.
 <5> `AroundInvoke` denotes a method that interposes on business methods.
@@ -448,7 +449,7 @@ public class LargeTxAccount implements Account { <3>
    @Any
    @Delegate
    Account delegate; <4>
-   
+
    @Inject
    LogService logService; <5>
 
@@ -458,10 +459,10 @@ public class LargeTxAccount implements Account { <3>
          logService.logWithdrawal(delegate, amount);
       }
    }
-    
+
 }
 ----
-<1> `@Priority` enables the decorator. Decorators with smaller priority values are called first. 
+<1> `@Priority` enables the decorator. Decorators with smaller priority values are called first.
 <2> `@Decorator` marks a decorator component.
 <3> The set of decorated types includes all bean types which are Java interfaces, except for `java.io.Serializable`.
 <4> Each decorator must declare exactly one _delegate injection point_. The decorator applies to beans that are assignable to this delegate injection point.
@@ -471,7 +472,7 @@ public class LargeTxAccount implements Account { <3>
 NOTE: Instances of decorators are dependent objects of the bean instance they intercept, i.e. a new decorator instance is created for each intercepted bean.
 
 === Events and Observers
-	
+
 Beans may also produce and consume events to interact in a completely decoupled fashion.
 Any Java object can serve as an event payload.
 The optional qualifiers act as topic selectors.

docs/src/main/asciidoc/extension-metadata.adoc

@@ -4,7 +4,6 @@ and pull requests should be submitted there:
 https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 ////
 = Quarkus Extension Metadata
-
 include::_attributes.adoc[]
 
 Quarkus extensions are distributed as Maven JAR artifacts that application and other libraries may depend on. When a Quarkus application project is built, tested or edited using the Quarkus dev tools, Quarkus extension JAR artifacts will be identified on the application classpath by the presence of the Quarkus extension metadata files in them.
@@ -127,11 +126,11 @@ The following properties may appear in this file:
 
 | `parent-first-artifacts`
 | Optional
-| Comma-separated list of artifact keys (`groupId:artifactId:classifier:type`) that are to be loaded in a parent first manner. This can be used to work around issues where a given class needs to be loaded by the system ClassLoader. 
+| Comma-separated list of artifact keys (`groupId:artifactId:classifier:type`) that are to be loaded in a parent first manner. This can be used to work around issues where a given class needs to be loaded by the system ClassLoader.
 
 | `runner-parent-first-artifacts`
 | Optional
-| Comma-separated list of artifact keys that are to be loaded in a parent first manner in addition to those configured with `parent-first-artifacts` when an application is launched from a production binary package. This can be used to work around issues where a given class needs to be loaded by the system ClassLoader. 
+| Comma-separated list of artifact keys that are to be loaded in a parent first manner in addition to those configured with `parent-first-artifacts` when an application is launched from a production binary package. This can be used to work around issues where a given class needs to be loaded by the system ClassLoader.
 
 | `excluded-artifacts`
 | Optional
@@ -143,7 +142,7 @@ The following properties may appear in this file:
 
 | `removed-resources.*`
 | Optional
-| Resources that should be removed/hidden from dependencies. This allows for classes and other resources to be removed from dependencies, so they are not accessible to the application. This is a map of artifact key to a comma-separated list of resources to be removed. When running in dev and test mode these resources are hidden from the ClassLoader, when running in production mode these files are removed from the jars that contain them. Note that if you want to remove a class you need to specify the class file name. e.g. to remove com.acme.Foo you would specify com/acme/Foo.class. 
+| Resources that should be removed/hidden from dependencies. This allows for classes and other resources to be removed from dependencies, so they are not accessible to the application. This is a map of artifact key to a comma-separated list of resources to be removed. When running in dev and test mode these resources are hidden from the ClassLoader, when running in production mode these files are removed from the jars that contain them. Note that if you want to remove a class you need to specify the class file name. e.g. to remove com.acme.Foo you would specify com/acme/Foo.class.
 
 | `provides-capabilities`
 | Optional

docs/src/main/asciidoc/grpc-virtual-threads.adoc

@@ -1,5 +1,9 @@
+////
+This guide is maintained in the main Quarkus repository
+and pull requests should be submitted there:
+https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
+////
 = Quarkus Virtual Thread support for gRPC services
-
 include::_attributes.adoc[]
 :runonvthread: https://javadoc.io/doc/io.smallrye.common/smallrye-common-annotation/latest/io/smallrye/common/annotation/RunOnVirtualThread.html
 :blocking_annotation: https://javadoc.io/doc/io.smallrye.reactive/smallrye-reactive-messaging-api/latest/io/smallrye/reactive/messaging/annotations/Blocking.html

docs/src/main/asciidoc/lifecycle.adoc

@@ -6,6 +6,7 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 = Application Initialization and Termination
 include::_attributes.adoc[]
 :categories: core
+:keywords: lifecycle event
 :summary: You often need to execute custom actions when the application starts and clean up everything when the application stops. This guide explains how to be notified when an application stops or starts.
 
 You often need to execute custom actions when the application starts and clean up everything when the application stops.
@@ -175,7 +176,7 @@ NOTE: The methods can access injected beans. Check the link:{quickstarts-blob-ur
 
 === What is the difference from `@Initialized(ApplicationScoped.class)` and `@Destroyed(ApplicationScoped.class)`
 
-In the JVM mode, there is no real difference, except that `StartupEvent` is always fired *after* `@Initialized(ApplicationScoped.class)` and `ShutdownEvent` is fired *before* `@Destroyed(ApplicationScoped.class)`. 
+In the JVM mode, there is no real difference, except that `StartupEvent` is always fired *after* `@Initialized(ApplicationScoped.class)` and `ShutdownEvent` is fired *before* `@Destroyed(ApplicationScoped.class)`.
 For a native executable build, however, `@Initialized(ApplicationScoped.class)` is fired as *part of the native build process*, whereas `StartupEvent` is fired when the native image is executed.
 See xref:writing-extensions.adoc#bootstrap-three-phases[Three Phases of Bootstrap and Quarkus Philosophy] for more details.
 
@@ -193,10 +194,10 @@ package org.acme.lifecycle;
 import io.quarkus.runtime.Startup;
 import jakarta.enterprise.context.ApplicationScoped;
 
-@Startup // <1> 
+@Startup // <1>
 @ApplicationScoped
 public class EagerAppBean {
-  
+
    private final String name;
 
    EagerAppBean(NameGenerator generator) { // <2>
@@ -222,10 +223,10 @@ import jakarta.enterprise.context.ApplicationScoped;
 
 @ApplicationScoped
 public class EagerAppBean {
-  
+
    @Startup
    void init() { <1>
-     doSomeCoolInit(); 
+     doSomeCoolInit();
    }
 }
 ----
@@ -234,7 +235,7 @@ public class EagerAppBean {
 [[shutdown_annotation]]
 === Using `@Shutdown` to execute a business method of a CDI bean during application shutdown
 
-The `@io.quarkus.runtime.Shutdown` annotation is used to mark a business method of a CDI bean that should be executed during application shutdown. 
+The `@io.quarkus.runtime.Shutdown` annotation is used to mark a business method of a CDI bean that should be executed during application shutdown.
 The annotated method must be non-private and non-static and declare no arguments.
 The behavior is similar to a declaration of a `ShutdownEvent` observer.
 The following examples are functionally equivalent.

docs/src/main/asciidoc/liquibase-mongodb.adoc

@@ -4,7 +4,6 @@ and pull requests should be submitted there:
 https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 ////
 = Using Liquibase MongoDB
-
 include::_attributes.adoc[]
 :change-log: src/main/resources/db/changeLog.xml
 :config-file: application.properties

docs/src/main/asciidoc/messaging-virtual-threads.adoc

@@ -1,5 +1,9 @@
+////
+This guide is maintained in the main Quarkus repository
+and pull requests should be submitted there:
+https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
+////
 = Quarkus Virtual Thread support with Reactive Messaging
-
 include::_attributes.adoc[]
 :runonvthread: https://javadoc.io/doc/io.smallrye.common/smallrye-common-annotation/latest/io/smallrye/common/annotation/RunOnVirtualThread.html
 :rm_blocking_annotation: https://javadoc.io/doc/io.smallrye.reactive/smallrye-reactive-messaging-api/latest/io/smallrye/reactive/messaging/annotations/Blocking.html

docs/src/main/asciidoc/mutiny-primer.adoc

@@ -4,7 +4,6 @@ and pull requests should be submitted there:
 https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 ////
 = Mutiny - Async for bare mortal
-
 include::_attributes.adoc[]
 
 https://smallrye.io/smallrye-mutiny[Mutiny] is an intuitive, reactive programming library.

docs/src/main/asciidoc/pulsar-dev-services.adoc

@@ -62,6 +62,6 @@ The following example enables transaction support:
 
 [source, properties]
 ----
-quarkus.pulsar.devservices.broker-config.transactionCoordinatorEnabled=true
-quarkus.pulsar.devservices.broker-config.systemTopicEnabled=true
+quarkus.pulsar.devservices.broker-config.transaction-coordinator-enabled=true
+quarkus.pulsar.devservices.broker-config.system-topic-enabled=true
 ----

docs/src/main/asciidoc/quarkus-maven-plugin.adoc

@@ -4,12 +4,11 @@ and pull requests should be submitted there:
 https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 ////
 = Quarkus Maven Plugin
+include::_attributes.adoc[]
 
 The Quarkus Maven Plugin builds the Quarkus applications, and provides helpers to launch dev mode or build native executables.
 For more information about how to use the Quarkus Maven Plugin, please refer to the xref:maven-tooling.adoc[Maven Tooling guide].
 
-include::_attributes.adoc[]
-
 == Discover Maven goals
 
 Like most Maven plugins, the Quarkus Maven Plugin has a `help` goal that prints the description of the plugin, listing all available goals as well as their description.