Rewrite code blocks from markdown style to asciidoc style

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

@@ -293,12 +293,13 @@ You can override the profile the executable is *built* with and *runs* with usin
 `./mvnw clean verify -Pnative -Dquarkus-profile=test`. This might come handy if there are test specific resources to be processed,
 such as importing test data into the database.
 
-```
+[source,properties]
+----
 quarkus.native.resources.includes=version.txt
 %test.quarkus.native.resources.includes=version.txt,import-dev.sql
 %test.quarkus.hibernate-orm.database.generation=drop-and-create
 %test.quarkus.hibernate-orm.sql-load-script=import-dev.sql
-```
+----
 
 With the aforementioned example in your `application.properties`, your Hibernate ORM managed database will be populated with test
 data both during the JVM mode test run and during the native mode test run. The production

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

@@ -136,9 +136,12 @@ The input of the build is the jar that has been built locally and the output of
 [NOTE]
 ====
 During the build you may find the `Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed` exception due to self-signed certificate. To solve this, just add the following line to your `application.properties`:
-```properties
+
+[source,properties]
+----
 quarkus.kubernetes-client.trust-certs=true
-```
+----
+
 For more information, see link:https://quarkus.io/guides/deploying-to-kubernetes#client-connection-configuration[deploying to kubernetes].
 ====
 

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

@@ -119,9 +119,10 @@ String jwt = Jwt.upn("Alice").jws().algorithm(SignatureAlgorithm.PS256).sign();
 
 Alternatively you can use a `smallrye.jwt.new-token.signature-algorithm` property:
 
-```properties
+[source,properties]
+----
 smallrye.jwt.new-token.signature-algorithm=PS256
-```
+----
 
 and write a simpler API sequence:
 
@@ -181,10 +182,11 @@ String jwt = Jwt.subject("Bob").jwe()
 
 Alternatively you can use `smallrye.jwt.new-token.key-encryption-algorithm` and `smallrye.jwt.new-token.content-encryption-algorithm` properties to customize the key and content encryption algorithms:
 
-```properties
+[source,properties]
+----
 smallrye.jwt.new-token.key-encryption-algorithm=RSA-OAEP-256
 smallrye.jwt.new-token.content-encryption-algorithm=A256CBC-HS512
-```
+----
 
 and write a simpler API sequence:
 

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

@@ -660,7 +660,8 @@ Use `mp.jwt.verify.publickey.algorithm` to customize the verification algorithm
 
 If you need to verify the token signature using the symmetric secret key then either a `JSON Web Key` (JWK) or `JSON Web Key Set` (JWK Set) format must be used to represent this secret key, for example:
 
-```json
+[source,json]
+----
 {
  "keys": [
    {
@@ -670,7 +671,7 @@ If you need to verify the token signature using the symmetric secret key then ei
    }
  ]
 }
-```
+----
 
 This secret key JWK will also need to be referred to with `smallrye.jwt.verify.key.location`.
 `smallrye.jwt.verify.algorithm` should be set to `HS256`/`HS384`/`HS512`.

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

@@ -3175,10 +3175,11 @@ Before publishing your extension to the xref:tooling.adoc[Quarkus tooling], make
 
 Then you must create a pull request adding a `your-extension.yaml` file in the `extensions/` directory in the link:https://github.com/quarkusio/quarkus-extension-catalog[Quarkus Extension Catalog]. The YAML must have the following structure:
 
-```yaml
+[source,yaml]
+----
 group-id: <YOUR_EXTENSION_RUNTIME_GROUP_ID>
 artifact-id: <YOUR_EXTENSION_RUNTIME_ARTIFACT_ID>
-```
+----
 
 That's all. Once the pull request is merged, a scheduled job will check Maven Central for new versions and update the xref:extension-registry-user.adoc[Quarkus Extension Registry].