Eliminating the white space from the xref macro

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

@@ -472,7 +472,7 @@ If one of those extensions is present, then creating a container image for the n
 ====
 If you're running a remote Docker daemon, you need to replace `quarkus.native.container-build=true` with `quarkus.native.remote-container-build=true`.
 
-See <<tip-quarkus-native-remote-container-build, Creating a Linux executable without GraalVM installed>> for more details.
+See <<tip-quarkus-native-remote-container-build,Creating a Linux executable without GraalVM installed>> for more details.
 ====
 
 * `quarkus.container-image.build=true` instructs Quarkus to create a container-image using the final application artifact (which is the native executable in this case)

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

@@ -553,7 +553,7 @@ It generates the UUID at startup time.
 So, the value changes between startups, including reloads in dev mode.
 
 You can access the generated value using the `quarkus.uuid` property.
-Use <<property-expressions, expressions>> to access it: `${quarkus.uuid}`.
+Use <<property-expressions,expressions>> to access it: `${quarkus.uuid}`.
 For example, it can be useful to configure a Kafka client with a unique consumer group:
 
 [source, properties]

docs/src/main/asciidoc/dev-mode-differences.adoc

@@ -31,7 +31,7 @@ In keeping with the mantra of providing developer joy, Quarkus provides a host o
 
 === Live reload
 
-This mightily important feature needs no introduction and has already been mentioned in the <<architectural-differences, architectural differences>> section.
+This mightily important feature needs no introduction and has already been mentioned in the <<architectural-differences,architectural differences>> section.
 
 === Dev UI
 

docs/src/main/asciidoc/hibernate-search-orm-elasticsearch.adoc

@@ -612,7 +612,7 @@ See also link:#quarkus-hibernate-search-orm-elasticsearch_quarkus.hibernate-sear
 
 
 [TIP]
-For more information about the Hibernate Search extension configuration please refer to the <<configuration-reference, Configuration Reference>>.
+For more information about the Hibernate Search extension configuration please refer to the <<configuration-reference,Configuration Reference>>.
 
 [[dev-services]]
 === Dev Services (Configuration Free Databases)

docs/src/main/asciidoc/jms.adoc

@@ -30,7 +30,7 @@ The data can be fetched from a browser using a fetch button from a Jakarta REST
 
 The guide can be used either via the Apache Qpid JMS AMQP client as detailed immediately below, or
 alternatively with the Apache ActiveMQ Artemis JMS client given some different configuration
-as <<artemis-jms, detailed later>>.
+as <<artemis-jms,detailed later>>.
 
 [#qpid-jms-amqp]
 == Qpid JMS - AMQP
@@ -330,7 +330,7 @@ Open `http://localhost:8080/prices.html` in your browser.
 
 The above steps detailed using the Qpid JMS AMQP client, however the guide can also be used
 with the Artemis JMS client. Many of the individual steps are exactly as previously
-<<qpid-jms-amqp, detailed above for Qpid JMS>>. The individual component code is the same.
+<<qpid-jms-amqp,detailed above for Qpid JMS>>. The individual component code is the same.
 The only differences are in the dependency for the initial project creation, and the
 configuration properties used. These changes are detailed below and should be substituted
 for the equivalent step during the sequence above.

docs/src/main/asciidoc/kafka.adoc

@@ -714,7 +714,7 @@ The `checkpoint` commit strategy is an experimental feature and can change in th
 
 Smallrye Reactive Messaging `checkpoint` commit strategy allows consumer applications to process messages in a stateful manner, while also respecting Kafka consumer scalability.
 An incoming channel with `checkpoint` commit strategy persists consumer offsets on an external 
-<<state-stores, state store>>, such as a relational database or a key-value store.
+<<state-stores,state store>>, such as a relational database or a key-value store.
 As a result of processing consumed records, the consumer application can accumulate an internal state for each topic-partition assigned to the Kafka consumer. 
 This local state will be periodically persisted to the state store and will be associated with the offset of the record that produced it.
 
@@ -1589,7 +1589,7 @@ NOTE: With JSON serialization correctly configured, you can also use `Publisher<
 === Serializing via Jackson
 
 Quarkus has built-in support for JSON serialization and deserialization based on Jackson.
-It will also <<serialization-generation, generate>> the serializer and deserializer for you, so you do not have to configure anything.
+It will also <<serialization-generation,generate>> the serializer and deserializer for you, so you do not have to configure anything.
 When generation is disabled, you can use the provided `ObjectMapperSerializer` and `ObjectMapperDeserializer` as explained below.
 
 There is an existing `ObjectMapperSerializer` that can be used to serialize all data objects via Jackson.

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

@@ -316,7 +316,7 @@ More details about this extension and its configuration can be found in the http
 
 
 [TIP]
-For more information about the Mailer configuration please refer to the <<configuration-reference, Configuration Reference>>.
+For more information about the Mailer configuration please refer to the <<configuration-reference,Configuration Reference>>.
 
 == Configuring a trust store
 

docs/src/main/asciidoc/security-customization.adoc

@@ -12,7 +12,7 @@ include::_attributes.adoc[]
 `io.quarkus:quarkus-security` module contains the core Quarkus Security classes.
 
 In most cases, it does not have to be added directly to your project's build file as it is already provided by all the security extensions.
-However, if you need to write your own custom security code (for example, register a <<jaxrs-security-context, Custom Jakarta REST SecurityContext>>) or use <<bouncy-castle, BouncyCastle>> libraries, then please make sure it is included:
+However, if you need to write your own custom security code (for example, register a <<jaxrs-security-context,Custom Jakarta REST SecurityContext>>) or use <<bouncy-castle,BouncyCastle>> libraries, then please make sure it is included:
 
 [source,xml,role="primary asciidoc-tabs-target-sync-cli asciidoc-tabs-target-sync-maven"]
 .pom.xml

docs/src/main/asciidoc/security-jwt-build.adoc

@@ -133,7 +133,7 @@ import io.smallrye.jwt.build.Jwt;
 String jwt = Jwt.upn("Alice").sign();
 ----
 
-Note the `sign` step can be combined with the <<encrypt-claims, encrypt>> step to produce `inner-signed and encrypted` tokens, see <<innersign-encrypt-claims, Sign the claims and encrypt the nested JWT token>> section.
+Note the `sign` step can be combined with the <<encrypt-claims,encrypt>> step to produce `inner-signed and encrypted` tokens, see <<innersign-encrypt-claims,Sign the claims and encrypt the nested JWT token>> section.
 
 [[encrypt-claims]]
 == Encrypt the claims
@@ -201,7 +201,7 @@ String jwt = Jwt.subject("Bob").encrypt();
 Note that when the token is directly encrypted by the public RSA or EC key it is not possible to verify which party sent the token.
 Therefore, the secret keys should be preferred for directly encrypting the tokens, for example, when using JWT as cookies where a secret key is managed by the Quarkus endpoint with only this endpoint being both a producer and a consumer of the encrypted token.
 
-If you would like to use RSA or EC public keys to encrypt the token then it is recommended to sign the token first if the signing key is available, see the next <<innersign-encrypt-claims, Sign the claims and encrypt the nested JWT token>> section.
+If you would like to use RSA or EC public keys to encrypt the token then it is recommended to sign the token first if the signing key is available, see the next <<innersign-encrypt-claims,Sign the claims and encrypt the nested JWT token>> section.
 
 [[innersign-encrypt-claims]]
 == Sign the claims and encrypt the nested JWT token

docs/src/main/asciidoc/security-jwt.adoc

@@ -742,7 +742,7 @@ public class SecuredResource {
 }
 ----
 
-Please also see the <<add-smallrye-jwt, How to Add SmallRye JWT directly>> section about using `JWTParser` without the `HTTP` support provided by `quarkus-smallrye-jwt`.
+Please also see the <<add-smallrye-jwt,How to Add SmallRye JWT directly>> section about using `JWTParser` without the `HTTP` support provided by `quarkus-smallrye-jwt`.
 
 === Token Decryption
 

docs/src/main/asciidoc/security-keycloak-authorization.adoc

@@ -192,13 +192,13 @@ quarkus.keycloak.policy-enforcer.enable=true
 quarkus.keycloak.devservices.realm-path=quarkus-realm.json
 ----
 
-NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in a dev mode. See <<keycloak-dev-mode, Running the Application in Dev mode>> section below for more information.
+NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in a dev mode. See <<keycloak-dev-mode,Running the Application in Dev mode>> section below for more information.
 
 NOTE: By default, applications using the `quarkus-oidc` extension are marked as a `service` type application (see `quarkus.oidc.application-type`). This extension also supports only  `web-app` type applications but only if the access token returned as part of the authorization code grant response is marked as a source of roles: `quarkus.oidc.roles.source=accesstoken` (`web-app` type applications check ID token roles by default).
 
 == Starting and Configuring the Keycloak Server
 
-NOTE: Do not start the Keycloak server when you run the application in a dev mode - `Dev Services for Keycloak` will launch a container. See <<keycloak-dev-mode, Running the Application in Dev mode>> section below for more information.
+NOTE: Do not start the Keycloak server when you run the application in a dev mode - `Dev Services for Keycloak` will launch a container. See <<keycloak-dev-mode,Running the Application in Dev mode>> section below for more information.
 
 To start a Keycloak Server you can use Docker and just run the following command:
 
@@ -277,7 +277,7 @@ After getting a cup of coffee, you'll be able to run this binary directly:
 
 == Testing the Application
 
-See <<keycloak-dev-mode, Running the Application in Dev mode>> section above about testing your application in a dev mode.
+See <<keycloak-dev-mode,Running the Application in Dev mode>> section above about testing your application in a dev mode.
 
 You can test the application launched in JVM or Native modes with `curl`.
 

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

@@ -267,7 +267,7 @@ quarkus.oidc.tls.trust-store-password=${trust-store-password}
 ==== Introspection endpoint authentication
 
 Some OIDC providers require authenticating to its introspection endpoint by using Basic authentication and with credentials that are different to the `client_id` and `client_secret`.
-If you have previously configured security authentication to support either the`client_secret_basic` or `client_secret_post` client authentication methods as described in the <<oidc-provider-client-authentication, OIDC provider client authentication>>  section, you might need to apply the additional configuration, as follows.
+If you have previously configured security authentication to support either the`client_secret_basic` or `client_secret_post` client authentication methods as described in the <<oidc-provider-client-authentication,OIDC provider client authentication>>  section, you might need to apply the additional configuration, as follows.
 
 If the tokens have to be introspected and the introspection endpoint-specific authentication mechanism is required, then you can configure `quarkus-oidc`, as follows:
 
@@ -677,7 +677,7 @@ quarkus.http.auth.permission.public.policy=permit
 ----
 
 You may also need to set `quarkus.oidc.authentication.cookie-path` to a path value common to all the application resources which is `/` in this example.
-For more information, see the <<oidc-cookies, Cookies>> section.
+For more information, see the <<oidc-cookies,Cookies>> section.
 
 [NOTE]
 ====
@@ -791,7 +791,7 @@ public class ServiceResource {
 [[oidc-session]]
 ====== Using `OidcSession` for local logout
 
-`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`, which can help to perform a <<local-logout, Local logout>>, retrieve the current session's tenant identifier, and check when the session will expire. 
+`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`, which can help to perform a <<local-logout,Local logout>>, retrieve the current session's tenant identifier, and check when the session will expire.
 More useful methods will be added to it over time.
 [[session-management]]
 
@@ -1327,7 +1327,7 @@ If a custom realm file has to be imported into Keycloak before running the tests
 quarkus.keycloak.devservices.realm-path=quarkus-realm.json
 ----
 
-Finally, write a test code the same way as it is described in the <<integration-testing-wiremock, Wiremock>> section.
+Finally, write a test code the same way as it is described in the <<integration-testing-wiremock,Wiremock>> section.
 The only difference is that `@QuarkusTestResource` is no longer needed:
 
 [source, java]
@@ -1384,7 +1384,7 @@ And configure the Maven Surefire plugin as follows:
 
 (and similarly the Maven Failsafe plugin when testing in native image).
 
-And now set the configuration and write the test code the same way as it is described in the <<integration-testing-wiremock, Wiremock>> section.
+And now set the configuration and write the test code the same way as it is described in the <<integration-testing-wiremock,Wiremock>> section.
 The only difference is the name of `QuarkusTestResource`:
 
 [source, java]

docs/src/main/asciidoc/security-openid-connect-client-reference.adoc

@@ -389,7 +389,7 @@ Note it will also bring `io.quarkus:quarkus-oidc-client`.
 
 `quarkus-oidc-client-reactive-filter` extension provides `io.quarkus.oidc.client.filter.OidcClientRequestReactiveFilter`.
 
-It works similarly to the way `OidcClientRequestFilter` does (see <<oidc-client-filter, Use OidcClient in MicroProfile RestClient client filter>>) - it uses `OidcClient` to acquire the access token, refresh it if needed, and set it as an HTTP `Authorization` `Bearer` scheme value. The difference is that it works with xref:rest-client-reactive.adoc[Reactive RestClient] and implements a non-blocking client filter which does not block the current IO thread when acquiring or refreshing the tokens.
+It works similarly to the way `OidcClientRequestFilter` does (see <<oidc-client-filter,Use OidcClient in MicroProfile RestClient client filter>>) - it uses `OidcClient` to acquire the access token, refresh it if needed, and set it as an HTTP `Authorization` `Bearer` scheme value. The difference is that it works with xref:rest-client-reactive.adoc[Reactive RestClient] and implements a non-blocking client filter which does not block the current IO thread when acquiring or refreshing the tokens.
 
 `OidcClientRequestReactiveFilter` delays an initial token acquisition until it is executed to avoid blocking an IO thread.
 
@@ -433,7 +433,7 @@ public interface ProtectedResourceService {
 
 `OidcClientRequestReactiveFilter` uses a default `OidcClient` by default. A named `OidcClient` can be selected with a `quarkus.oidc-client-reactive-filter.client-name` configuration property.
 You can also select `OidcClient` by setting `value` attribute of the `@OidcClientFilter` annotation. The client name set through annotation has higher priority than the `quarkus.oidc-client-reactive-filter.client-name` configuration property.
-For example, given <<use-oidc-clients, this>> `jwt-secret` named OIDC client declaration, you can refer to this client like this:
+For example, given <<use-oidc-clients,this>> `jwt-secret` named OIDC client declaration, you can refer to this client like this:
 
 [source,java]
 ----
@@ -510,7 +510,7 @@ Alternatively, `OidcClientRequestFilter` can be registered automatically with al
 
 `OidcClientRequestFilter` uses a default `OidcClient` by default. A named `OidcClient` can be selected with a `quarkus.oidc-client-filter.client-name` configuration property.
 You can also select `OidcClient` by setting `value` attribute of the `@OidcClientFilter` annotation. The client name set through annotation has higher priority than the `quarkus.oidc-client-filter.client-name` configuration property.
-For example, given <<use-oidc-clients, this>> `jwt-secret` named OIDC client declaration, you can refer to this client like this:
+For example, given <<use-oidc-clients,this>> `jwt-secret` named OIDC client declaration, you can refer to this client like this:
 
 [source,java]
 ----

docs/src/main/asciidoc/security-openid-connect-client.adoc

@@ -329,11 +329,11 @@ org.acme.security.openid.connect.client.RestClientWithTokenPropagationFilter/mp-
 
 This configuration references Keycloak which will be used by `ProtectedResource` to verify the incoming access tokens and by `OidcClient` to get the tokens for a user `alice` using a `password` grant. Both RESTClients point to `ProtectedResource`'s HTTP address.
 
-NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in dev or test modes. See <<keycloak-dev-mode, Running the Application in Dev mode>> section below for more information.
+NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` will launch a container for you when the application is run in dev or test modes. See <<keycloak-dev-mode,Running the Application in Dev mode>> section below for more information.
 
 == Starting and Configuring the Keycloak Server
 
-NOTE: Do not start the Keycloak server when you run the application in dev mode or test modes - `Dev Services for Keycloak` will launch a container. See <<keycloak-dev-mode, Running the Application in Dev mode>> section below for more information. Make sure to put the link:{quickstarts-tree-url}/security-openid-connect-client-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath (`target/classes` directory) so that it gets imported automatically when running in dev mode - unless you have already built a link:{quickstarts-tree-url}/security-openid-connect-quickstart[complete solution] in which case this realm file will be added to the classpath during the build.
+NOTE: Do not start the Keycloak server when you run the application in dev mode or test modes - `Dev Services for Keycloak` will launch a container. See <<keycloak-dev-mode,Running the Application in Dev mode>> section below for more information. Make sure to put the link:{quickstarts-tree-url}/security-openid-connect-client-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath (`target/classes` directory) so that it gets imported automatically when running in dev mode - unless you have already built a link:{quickstarts-tree-url}/security-openid-connect-quickstart[complete solution] in which case this realm file will be added to the classpath during the build.
 
 To start a Keycloak Server you can use Docker and just run the following command:
 
@@ -411,7 +411,7 @@ After getting a cup of coffee, you'll be able to run this binary directly:
 
 == Testing the Application
 
-See <<keycloak-dev-mode, Running the Application in Dev mode>> section above about testing your application in dev mode.
+See <<keycloak-dev-mode,Running the Application in Dev mode>> section above about testing your application in dev mode.
 
 You can test the application launched in JVM or Native modes with `curl`.