Apply suggestions from code review

Co-authored-by: Erin Schnabel <ebullientworks@gmail.com>
Co-authored-by: Mickey Maler <mmaler@redhat.com>

docs/src/main/asciidoc/rest-data-panache.adoc

@@ -27,7 +27,7 @@ Please, check out the next compatibility table to use the right one according to
 |`ORM`
 |`Classic and Reactive`
 
-|<<hr-hibernate-reactive, quarkus-hibernate-reactive-rest-data-panache>>
+|<<hr-hibernate-reactive,quarkus-hibernate-reactive-rest-data-panache>>
 |`Reactive`
 |`Reactive`
 

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

@@ -178,7 +178,8 @@ For more information, see xref:security-openid-connect-oidc-configuration-proper
 
 === Start and configure the Keycloak server
 
-Before you start with configuration, put the {quickstarts-tree-url}/security-openid-connect-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath (`target/classes` directory) to import it automatically when running in dev mode - unless you have already built a {quickstarts-tree-url}/security-openid-connect-quickstart[complete solution]. In this case, the realm file is added to the classpath during the build.
+Before you start with configuration, put the {quickstarts-tree-url}/security-openid-connect-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath (`target/classes` directory) to import it automatically when running in dev mode - unless you have already built a {quickstarts-tree-url}/security-openid-connect-quickstart[complete solution].
+In this case, the realm file is added to the classpath during the build.
 
 [NOTE]
 ====

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

@@ -71,7 +71,8 @@ noadmin=n0Adm1n
 <1> User `scott` has password defined as `jb0ss`
 <2> User `jdoe` has password defined as `p4ssw0rd`
 
-This file has usernames and passwords stored in plain text, which is not recommended. If plain text is set to false (or omitted) in the config, then passwords must be stored in the form `MD5 ( username : realm : password )`. This can be generated for the first example above by running the command `echo -n scott:MyRealm:jb0ss | md5` from the command line.
+This file has usernames and passwords stored in plain text, which is not recommended. If plain text is set to false (or omitted) in the config, then passwords must be stored in the form `MD5 ( username : realm : password )`.
+This can be generated for the first example above by running the command `echo -n scott:MyRealm:jb0ss | md5` from the command line.
 
 ==== Roles.properties
 
@@ -89,7 +90,8 @@ noadmin=user
 
 === Embedded Realm Configuration
 
-The embedded realm also supports the mapping of users to passwords and users to roles. It uses the main `application.properties` Quarkus configuration file to embed this information. They are configured with properties starting with `quarkus.security.users.embedded`.
+The embedded realm also supports the mapping of users to passwords and users to roles. It uses the main `application.properties` Quarkus configuration file to embed this information.
+They are configured with properties starting with `quarkus.security.users.embedded`.
 
 The following is an example application.properties file section illustrating the embedded realm configuration:
 
@@ -114,7 +116,8 @@ This can be generated for the first example above by running the command `echo -
 
 ==== Embedded Users
 
-The user to password mappings are specified in the `application.properties` file by properties keys of the form `quarkus.security.users.embedded.users.<user>=<password>`. The following <<password-example>> illustrates the syntax with 4 user-to-password mappings:
+The user to password mappings are specified in the `application.properties` file by properties keys of the form `quarkus.security.users.embedded.users.<user>=<password>`.
+The following <<password-example>> illustrates the syntax with 4 user-to-password mappings:
 
 [#password-example]
 .Example of passwords
@@ -130,7 +133,8 @@ quarkus.security.users.embedded.users.noadmin=n0Adm1n
 
 ==== Embedded Roles
 
-The user to role mappings are specified in the `application.properties` file by properties keys of the form `quarkus.security.users.embedded.roles.<user>=role1[,role2[,role3[,...]]]`. The following <<roles-example>> illustrates the syntax with 4 user-to-role mappings:
+The user to role mappings are specified in the `application.properties` file by properties keys of the form `quarkus.security.users.embedded.roles.<user>=role1[,role2[,role3[,...]]]`.
+The following <<roles-example>> illustrates the syntax with 4 user-to-role mappings:
 
 [#roles-example]
 .Example of roles

docs/src/main/asciidoc/writing-extensions.adoc

@@ -339,7 +339,8 @@ There are three distinct bootstrap phases of a Quarkus app:
 Augmentation::
     This is the first phase, and is done by the <<build-step-processors>>. These processors have access to Jandex annotation
     information and can parse any descriptors and read annotations, but should not attempt to load any application classes. The output of these
-    build steps is some recorded bytecode, using an extension of the ObjectWeb ASM project called Gizmo(ext/gizmo), that is used to actually bootstrap the application at runtime. Depending on the `io.quarkus.deployment.annotations.ExecutionTime` value of the `@io.quarkus.deployment.annotations.Record` annotation associated with the build step,
+    build steps is some recorded bytecode, using an extension of the ObjectWeb ASM project called Gizmo(ext/gizmo), that is used to actually bootstrap the application at runtime.
+    Depending on the `io.quarkus.deployment.annotations.ExecutionTime` value of the `@io.quarkus.deployment.annotations.Record` annotation associated with the build step,
     the step may be run in a different JVM based on the following two modes.
 
 Static Init::
@@ -2426,7 +2427,8 @@ public class ConfiguredBean implements IConfigConsumer {
 
 [[parsing-config-to-objects]]
 ==== Parsing Config to Objects
-One of the main things an extension is likely to do is completely separate the configuration phase of behavior from the runtime phase. Frameworks often do parsing/load of configuration on startup that can be done during build time to both reduce the runtime dependencies on frameworks like xml parsers as well as reducing the startup time the parsing incurs.
+One of the main things an extension is likely to do is completely separate the configuration phase of behavior from the runtime phase.
+Frameworks often do parsing/load of configuration on startup that can be done during build time to both reduce the runtime dependencies on frameworks like xml parsers as well as reducing the startup time the parsing incurs.
 
 An example of parsing an XML config file using JAXB is shown in the `TestProcessor#parseServiceXmlConfig` method:
 .Parsing an XML Configuration into Runtime XmlConfig Instance
@@ -2462,7 +2464,8 @@ If for some reason you need to parse the config and use it in other build steps
 
 [TIP]
 ====
-If you look at the XmlConfig code you will see that it does carry around the JAXB annotations. If you don't want these in the runtime image, you could clone the XmlConfig instance into some POJO object graph and then replace XmlConfig with the POJO class. We will do this in <<replacing-classes-in-native-image>>.
+If you look at the XmlConfig code you will see that it does carry around the JAXB annotations. If you don't want these in the runtime image, you could clone the XmlConfig instance into some POJO object graph and then replace XmlConfig with the POJO class.
+We will do this in <<replacing-classes-in-native-image>>.
 ====
 
 ==== Scanning Deployments Using Jandex
@@ -2540,7 +2543,10 @@ You can use the `io.quarkus.arc.runtime.BeanContainer` interface to interact wit
 
 [[manage-non-cdi-service]]
 ==== Manage Non-CDI Service
-A common purpose for an extension is to integrate a non-CDI aware service into the CDI based Quarkus runtime. Step 1 of this task is to load any configuration needed in a STATIC_INIT build step as we did in <<parsing-config-to-objects>>. Now we need to create an instance of the service using the configuration. Let's return to the `TestProcessor#parseServiceXmlConfig` method to see how this can be done.
+A common purpose for an extension is to integrate a non-CDI aware service into the CDI based Quarkus runtime.
+Step 1 of this task is to load any configuration needed in a STATIC_INIT build step as we did in <<parsing-config-to-objects>>.
+Now we need to create an instance of the service using the configuration.
+Let's return to the `TestProcessor#parseServiceXmlConfig` method to see how this can be done.
 
 .Creating a Non-CDI Service
 [source,java]
@@ -2588,7 +2594,8 @@ A common purpose for an extension is to integrate a non-CDI aware service into t
 
 [[starting-service]]
 ===== Starting a Service
-Now that you have recorded the creation of a service during the build phase, you need to record how to start the service at runtime during booting. You do this with a RUNTIME_INIT build step as shown in the `TestProcessor#startRuntimeService` method.
+Now that you have recorded the creation of a service during the build phase, you need to record how to start the service at runtime during booting.
+You do this with a RUNTIME_INIT build step as shown in the `TestProcessor#startRuntimeService` method.
 
 .Starting/Stopping a Non-CDI Service
 [source,java]
@@ -2660,7 +2667,8 @@ public class SomeBean {
 <2> Observe a `ShutdownEvent` to be notified when the runtime is going to shut down.
 
 What is the relevance of startup and shutdown events for extension authors? We have already seen the use of a `ShutdownContext`
-to register a callback to perform shutdown tasks in the <<starting-service>> section. These shutdown tasks would be called
+to register a callback to perform shutdown tasks in the <<starting-service>> section.
+These shutdown tasks would be called
 after a `ShutdownEvent` had been sent.
 
 A `StartupEvent` is fired after all `io.quarkus.deployment.builditem.ServiceStartBuildItem` producers have been consumed.
@@ -2907,7 +2915,8 @@ An extension registers this substitution by producing an `ObjectSubstitutionBuil
 
 [[replacing-classes-in-native-image]]
 ==== Replacing Classes in the Native Image
-The Graal SDK supports substitutions of classes in the native image. An example of how one could replace the `XmlConfig/XmlData` classes with versions that have no JAXB annotation dependencies is shown in these example classes:
+The Graal SDK supports substitutions of classes in the native image.
+An example of how one could replace the `XmlConfig/XmlData` classes with versions that have no JAXB annotation dependencies is shown in these example classes:
 
 .Substitution of XmlConfig/XmlData Classes Example
 [source,java]