Use [[anchor]] format consistently

(cherry picked from commit a309b30)

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

@@ -369,7 +369,7 @@ mp.messaging.incoming.people-out.link-name=people
 
 More details about the AMQP Address model can be found in the https://activemq.apache.org/components/artemis/documentation/2.0.0/address-model.html[Artemis documentation].
 
-[#blocking-processing]
+[[blocking-processing]]
 === Execution model and Blocking processing
 
 Reactive Messaging invokes your method on an I/O thread.

docs/src/main/asciidoc/azure-functions-http.adoc

@@ -85,7 +85,7 @@ The Azure Functions `host.json` deployment descriptor is automatically
 generated, but if you need to override it, declare it in the root directory of the project and
 rerun the build when you are ready.
 
-[#config-azure-paths]
+[[config-azure-paths]]
 == Configuring Root Paths
 
 The default route prefix for an Azure Function is `/api`.  All of your Jakarta REST, Servlet, Reactive Routes, and xref:funqy-http.adoc[Funqy HTTP] endpoints must

docs/src/main/asciidoc/building-native-image.adoc

@@ -379,7 +379,7 @@ It is also possible to re-run the tests against a native executable that has alr
 If the process cannot find the native image for some reason, or you want to test a native image that is no longer in the
 target directory you can specify the executable with the `-Dnative.image.path=` system property.
 
-[#container-runtime]
+[[container-runtime]]
 == Creating a Linux executable without GraalVM installed
 
 IMPORTANT: Before going further, be sure to have a working container runtime (Docker, podman) environment. If you use Docker
@@ -415,7 +415,7 @@ These are regular Quarkus config properties, so if you always want to build in a
 it is recommended you add these to your `application.properties` in order to avoid specifying them every time.
 ====
 
-[#tip-quarkus-native-remote-container-build]
+[[tip-quarkus-native-remote-container-build]]
 [TIP]
 ====
 If you see the following invalid path error for your application JAR when trying to create a native executable using a container build, even though your JAR was built successfully, you're most likely using a remote daemon for your container runtime.
@@ -548,7 +548,7 @@ CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
 The UBI minimal image is bigger than the micro one mentioned above.
 It contains more utilities such as the `microdnf` package manager.
 
-[#multistage-docker]
+[[multistage-docker]]
 === Using a multi-stage Docker build
 
 The previous section showed you how to build a native executable using Maven or Gradle, but it requires you to have created the native executable first.

docs/src/main/asciidoc/cache.adoc

@@ -273,7 +273,7 @@ Congratulations! You just added application data caching to your Quarkus applica
 Do you want to learn more about the Quarkus application data caching abilities?
 The following sections will show you everything there is to know about it.
 
-[#annotations-api]
+[[annotations-api]]
 == Caching using annotations
 
 Quarkus offers a set of annotations that can be used in a CDI managed bean to enable caching abilities.
@@ -327,7 +327,7 @@ method annotated with `@CacheResult` or `@CacheInvalidate`.
 
 This annotation is optional and should only be used when some method arguments are NOT part of the cache key.
 
-[#cache-keys-building-logic]
+[[cache-keys-building-logic]]
 === Cache keys building logic
 
 Cache keys are built by the annotations API using the following logic:
@@ -489,7 +489,7 @@ public class CachedService {
 <3> This key generator is not a CDI bean.
 <4> The `@CacheKey` annotation will be ignored when the `foo` cache data is invalidated, but `param1` will be the cache key when the `bar` cache data is invalidated.
 
-[#programmatic-api]
+[[programmatic-api]]
 == Caching using the programmatic API
 
 Quarkus also offers a programmatic API which can be used to store, retrieve or delete values from any cache declared using the annotations API.
@@ -966,7 +966,7 @@ public class CacheClearer {
 }
 ----
 
-[#negative-cache]
+[[negative-cache]]
 == Negative caching and nulls
 
 Sometimes one wants to cache the result of an (expensive) remote call.

docs/src/main/asciidoc/container-image.adoc

@@ -19,7 +19,7 @@ Quarkus provides extensions for building (and pushing) container images. Current
 
 == Container Image extensions
 
-[#jib]
+[[jib]]
 === Jib
 
 The extension `quarkus-container-image-jib` is powered by https://github.com/GoogleContainerTools/jib[Jib] for performing container image builds.
@@ -106,7 +106,7 @@ this property needs to be known very early on in the build process.
 Quarkus supports generating and including an link:https://docs.oracle.com/en/java/javase/17/docs/specs/man/java.html#application-class-data-sharing[Application Class Data Sharing] archive when generating a container image using Jib.
 See the xref:appcds.adoc[AppCDS documentation] for more details.
 
-[#docker]
+[[docker]]
 === Docker
 
 The extension `quarkus-container-image-docker` is using the Docker binary and the generated Dockerfiles under `src/main/docker` in order to perform Docker builds.
@@ -120,7 +120,7 @@ The `quarkus-container-image-docker` extension is capable of https://docs.docker
 
 NOTE: `docker buildx build` ONLY supports https://docs.docker.com/engine/reference/commandline/buildx_build/#load[loading the result of a build] to `docker images` when building for a single platform. Therefore, if you specify more than one argument in the `quarkus.docker.buildx.platform` property, the resulting images will not be loaded into `docker images`. If `quarkus.docker.buildx.platform` is omitted or if only a single platform is specified, it will then be loaded into `docker images`.
 
-[#openshift]
+[[openshift]]
 === OpenShift
 
 The extension `quarkus-container-image-openshift` is using OpenShift binary builds in order to perform container builds inside the OpenShift cluster.
@@ -137,7 +137,7 @@ OpenShift builds require creating a `BuildConfig` and two `ImageStream` resource
 The creation of such objects is being taken care of by the Quarkus Kubernetes extension.
 
 
-[#buildpack]
+[[buildpack]]
 === Buildpack
 
 The extension `quarkus-container-image-buildpack` is using buildpacks in order to perform container image builds.
@@ -248,7 +248,7 @@ In addition to the generic container image options, the `container-image-jib` al
 
 include::{generated-dir}/config/quarkus-container-image-jib.adoc[opts=optional, leveloffset=+1]
 
-[#DockerOptions]
+[[DockerOptions]]
 === Docker Options
 
 In addition to the generic container image options, the `container-image-docker` also provides the following options:

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

@@ -22,7 +22,7 @@ Finally, when either one of container image extensions is present (see the xref:
 include::{includes}/prerequisites.adoc[]
 * Access to a Kubernetes cluster (Minikube is a viable option)
 
-[#kubernetes]
+[[kubernetes]]
 == Kubernetes
 
 Let's create a new project that contains both the Kubernetes and Jib extensions:
@@ -400,7 +400,7 @@ quarkus.kubernetes.annotations.foo=bar
 quarkus.kubernetes.annotations."app.quarkus/id"=42
 ----
 
-[#env-vars]
+[[env-vars]]
 ==== Environment variables
 
 Kubernetes provides multiple ways of defining environment variables:
@@ -538,7 +538,7 @@ A conflict between two definitions, e.g. mistakenly assigning both a value and s
 
 Similarly, two redundant definitions, e.g. defining an injection from the same secret twice, will not cause an issue but will indeed report a warning to let you know that you might not have intended to duplicate that definition.
 
-[#env-vars-backwards]
+[[env-vars-backwards]]
 ===== Backwards compatibility
 
 Previous versions of the Kubernetes extension supported a different syntax to add environment variables. The older syntax is still supported but is deprecated, and it's advised that you migrate to the new syntax.
@@ -1084,7 +1084,7 @@ The full list of the Kubernetes client configuration properties is provided belo
 :no-duration-note: true
 include::{generated-dir}/config/quarkus-kubernetes-client.adoc[opts=optional, leveloffset=+1]
 
-[#openshift]
+[[openshift]]
 === OpenShift
 
 One way to deploy an application to OpenShift is to use s2i (source to image) to create an image stream from the source and then deploy the image stream:
@@ -1195,7 +1195,7 @@ The OpenShift resources can be customized in a similar approach with Kubernetes.
 :no-duration-note: true
 include::{generated-dir}/config/quarkus-openshift-openshift-config.adoc[opts=optional, leveloffset=+1]
 
-[#knative]
+[[knative]]
 === Knative
 
 To enable the generation of Knative resources, you need to include Knative in the target platforms:

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

@@ -92,7 +92,7 @@ include::{includes}/devtools/build.adoc[]
 
 TIP: If you want to test your application immediately then set the `quarkus.openshift.route.expose` config property to `true` to <<exposing_routes,expose the service automatically>>, e.g. add `-Dquarkus.openshift.route.expose=true` to the command above.
 
-[#re-deploy-with-service-binding]
+[[re-deploy-with-service-binding]]
 NOTE: When using `DeploymentConfig` and xref:deploying-to-kubernetes.adoc#service_binding[Service Binding], re-deploying might remove the configuration added by OpenShift to allow service discovery. A new container image build will trigger a refresh of the Quarkus app in OpenShift: `-Dquarkus.container-image.build=true` which might be enough in most situations. If you need to update the OpenShift resources, you need to delete the binding first to create it again after new deployment.
 
 This command will build your application locally, then trigger a container image build and finally apply the generated OpenShift resources automatically.
@@ -273,7 +273,7 @@ To add an annotation in the generated resources:
 quarkus.openshift.annotations.foo=bar
 ----
 
-[#env-vars]
+[[env-vars]]
 === Environment variables
 
 OpenShift provides multiple ways of defining environment variables:
@@ -440,7 +440,7 @@ A conflict between two definitions, e.g. mistakenly assigning both a value and s
 
 Similarly, two redundant definitions, e.g. defining an injection from the same secret twice, will not cause an issue but will indeed report a warning to let you know that you might not have intended to duplicate that definition.
 
-[#env-vars-backwards]
+[[env-vars-backwards]]
 ===== Backwards compatibility
 
 Previous versions of the OpenShift extension supported a different syntax to add environment variables. The older syntax is still supported but is deprecated, and it's advised that you migrate to the new syntax.

docs/src/main/asciidoc/dev-ui.adoc

@@ -841,7 +841,7 @@ The router is mostly used internally. This uses https://github.com/vaadin/router
 
 See the https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/dev-ui-resources/src/main/resources/dev-ui/controller/router-controller.js[controller] for some methods that might be useful.
 
-[#JsonRPC]
+[[JsonRPC]]
 ====== JsonRPC
 
 This controller allows you to fetch or stream runtime data. (vs. <<Build time data>> discussed earlier). There are two parts to getting data during runtime. The Java side in the runtime module, and then the usage in the web component.

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

@@ -347,14 +347,14 @@ public class ConfigYamlCodestartTest {
 
 == Specific topics
 
-[#org-acme-package]
+[[org-acme-package]]
 === `org.acme` placeholder for package name
 
 You have to use `org.acme` as the package name in your extension codestart sources. In the generated project, the user specified package (or Group) will be used (and automatically replace `org.acme`).
 
 The package will be automatically replaced in all the source files (.java, .kt, .scala). The package directory will also be automatically adjusted. If for some reason, another type of file needs the user package name then you should use a <<qute-templates>> for it and the `{project.package-name}` data placeholder (https://github.com/quarkusio/quarkus/blob/main/devtools/project-core-extension-codestarts/src/main/resources/codestarts/quarkus/extension-codestarts/grpc-codestart/base/src/main/proto/hello.tpl.qute.proto#L4[find an example in the grpc proto file, window="_blank"]).
 
-[#codestart-yml]
+[[codestart-yml]]
 === codestart.yml
 
 [source,yaml]
@@ -376,7 +376,7 @@ metadata:
   path: /some-path
 ----
 
-[#directory-structure]
+[[directory-structure]]
 === Directory Structure
 
 NOTE: `codestart.yml` is the only required file.
@@ -428,7 +428,7 @@ maven-surefire-plugin.version = Maven Surefire plugin version
 * certain common files, such as `readme.md`, `src/main/resources/application.yml`, `src/main/resources/META-INF/resources/index.html` are generated from the collected fragments found in the selected codestarts for the project
 * other files are copied.
 
-[#qute-templates]
+[[qute-templates]]
 === Templates (Qute)
 
 Codestarts may use Qute templates `MyClass.tpl.qute.java` for dynamic rendering.
@@ -440,7 +440,7 @@ Those templates are able to use data which contains:
 * The user input
 * Some dynamically generated data (e.g. `dependencies` and `test-dependencies`)
 
-[#readme-md]
+[[readme-md]]
 === README.md
 
 You may add a `README.md` or `README.tpl.qute.md` in the `base` directory, it will be appended to the others.
@@ -456,7 +456,7 @@ base/README.tpl.qute.md
 
 NOTE: The `{#include readme-header /}` will use a template located in the Quarkus project codestart which displays standard info from the `codestart.yml` metadata.
 
-[#app-config]
+[[app-config]]
 === application config application.yml
 
 As a convention, you should always provide the Quarkus configuration as a yaml file (`base/src/main/resources/application.yml`).
@@ -466,7 +466,7 @@ It is going to be:
 * merged with the other extension codestarts configs
 * automatically converted to the selected config type (yaml or properties) at generation time depending on the selected extensions
 
-[#index-html]
+[[index-html]]
 === index.html and web extension codestarts
 
 Extension codestarts may provide a snippet for the generated index.html by adding this file:
@@ -479,7 +479,7 @@ base/src/main/resources/META-INF/resources/index.entry.qute.html:
 
 NOTE: The `{#include index-entry /}` will use a template located in the Quarkus project codestart which displays standard info from the `codestart.yml` metadata.
 
-[#integration-test]
+[[integration-test]]
 === Integration test
 
 An extension is available to help test extension codestarts `QuarkusCodestartTest`:
@@ -504,7 +504,7 @@ The extension provides helpers to test that the projects build `buildAllProjects
 
 The https://github.com/quarkusio/quarkus/blob/main/integration-tests/devtools/src/test/java/io/quarkus/devtools/codestarts/quarkus/ConfigYamlCodestartTest.java[ ConfigYamlCodestartTest, window="_blank"] is a good example in Quarkus core.
 
-[#snapshot-testing]
+[[snapshot-testing]]
 ==== Snapshot testing
 
 Snapshot testing is a way to make sure the content generated by a test doesn't change from one revision to another, i.e. between commits. That means, the generated content for each commit needs to be immutable and deterministic (this is the reason for using mocked data). To be able to perform such checks, we auto-generate snapshots of the generated content  and commit them as the references of the expected output for subsequent test runs. When the templates change, we also commit the induced snapshots changes. This way, during the review, we can make sure the applied code changes have the expected effects on the generated output.

docs/src/main/asciidoc/extension-registry-user.adoc

@@ -182,7 +182,7 @@ Some options need to be set:
 
 Here is an example on how it should look like:
 
-[#img-nexus]
+[[img-nexus]]
 .Nexus Repository Manager: Add Proxy Repository
 image:registry-nexus-repository.png[Nexus Repository Proxy]
 

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

@@ -1070,7 +1070,7 @@ If you are using the `quarkus-hibernate-orm-panache` or `quarkus-mongodb-panache
 
 If you are using Quarkus Security, check out the xref:security-testing.adoc[Testing Security] section for information on how to easily test security features of the application.
 
-[#quarkus-test-resource]
+[[quarkus-test-resource]]
 == Starting services before the Quarkus application starts
 
 A very common need is to start some services on which your Quarkus application depends, before the Quarkus application starts for testing. To address this need, Quarkus provides `@io.quarkus.test.common.QuarkusTestResource` and `io.quarkus.test.common.QuarkusTestResourceLifecycleManager`.
@@ -1242,7 +1242,7 @@ guide except injecting into tests (and the native executable runs in a separate
 
 This is covered in the xref:building-native-image.adoc[Native Executable Guide].
 
-[#quarkus-integration-test]
+[[quarkus-integration-test]]
 == Using `@QuarkusIntegrationTest`
 
 `@QuarkusIntegrationTest` should be used to launch and test the artifact produced by the Quarkus build, and supports testing a jar (of whichever type), a native image or container image.

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

@@ -456,7 +456,7 @@ NOTE: If you want to deploy your application somewhere (typically in a container
 
 NOTE: Before running the application, don't forget to stop the hot reload mode (hit `CTRL+C`), or you will have a port conflict.
 
-[#banner]
+[[banner]]
 == Configuring the banner
 
 By default, when a Quarkus application starts (in regular or dev mode), it will display an ASCII art banner. The banner can be disabled by setting `quarkus.banner.enabled=false` in `application.properties`,

docs/src/main/asciidoc/infinispan-client-reference.adoc

@@ -666,7 +666,7 @@ for Kubernetes deployments, Infinispan Console,
 https://infinispan.org/docs/stable/titles/rest/rest.html#rest_v2_protobuf_schemas[REST API] or the
 https://infinispan.org/docs/stable/titles/encoding/encoding.html#registering-sci-remote-caches_marshalling[Hot Rod Java Client].
 
-[#infinispan-annotations-api]
+[[infinispan-annotations-api]]
 == Caching using annotations
 
 The Infinispan Client extension offers a set of annotations that can be used in a CDI managed bean to enable caching abilities with Infinispan.

docs/src/main/asciidoc/jms.adoc

@@ -33,7 +33,7 @@ The guide can be used either via the Apache Qpid JMS AMQP client as detailed imm
 alternatively with the Apache ActiveMQ Artemis JMS client given some different configuration
 as <<artemis-jms,detailed later>>.
 
-[#qpid-jms-amqp]
+[[qpid-jms-amqp]]
 == Qpid JMS - AMQP
 
 In the detailed steps below we will use the https://qpid.apache.org/components/jms/[Apache Qpid JMS]
@@ -75,7 +75,7 @@ This command generates a new project importing the quarkus-qpid-jms extension:
 implementation("org.amqphub.quarkus:quarkus-qpid-jms")
 ----
 
-[#starting-the-broker]
+[[starting-the-broker]]
 === Starting the broker
 
 Then, we need an AMQP broker. In this case we will use an Apache ActiveMQ Artemis server.
@@ -294,7 +294,7 @@ quarkus.qpid-jms.password=quarkus
 
 More detail about the configuration are available in the https://github.com/amqphub/quarkus-qpid-jms#configuration[Quarkus Qpid JMS] documentation.
 
-[#get-it-running]
+[[get-it-running]]
 === Get it running
 
 If you followed the instructions, you should have the Artemis server running.
@@ -326,7 +326,7 @@ Open `http://localhost:8080/prices.html` in your browser.
 '''
 
 
-[#artemis-jms]
+[[artemis-jms]]
 == Artemis JMS
 
 The above steps detailed using the Qpid JMS AMQP client, however the guide can also be used

docs/src/main/asciidoc/kafka.adoc

@@ -237,7 +237,7 @@ Injecting `@Channel("prices")` or having `@Incoming("prices")` does not automati
 You need to configure an inbound connector with `mp.messaging.incoming.prices\...` or have an `@Outgoing("prices")` method somewhere in your application (in which case, `prices` will be an in-memory channel).
 ====
 
-[#blocking-processing]
+[[blocking-processing]]
 === Blocking processing
 
 Reactive Messaging invokes your method on an I/O thread.
@@ -2775,7 +2775,7 @@ mp.messaging.incoming.fruits.value.deserializer=org.acme.FruitDeserializer
 Check <<jackson-serialization>> for more detail about the usage of Jackson with Kafka.
 You can also use Avro.
 
-[#persisting-kafka-messages-with-hibernate-reactive]
+[[persisting-kafka-messages-with-hibernate-reactive]]
 === Persisting Kafka messages with Hibernate Reactive
 
 To persist objects received from Kafka into a database, you can use Hibernate Reactive with Panache.
@@ -2922,7 +2922,7 @@ public class ResourceSendingToKafka {
 <3> Wrap the managed entity inside a Data transfer object and send it to Kafka.
 This makes sure that managed entity is not impacted by the Kafka serialization.
 
-[#writing-entities-managed-by-hibernate-reactive-to-kafka]
+[[writing-entities-managed-by-hibernate-reactive-to-kafka]]
 === Writing entities managed by Hibernate Reactive to Kafka
 
 To send to Kafka entities managed by Hibernate Reactive, we recommend using: