anchor.diff:  For more information about the extension configuration please refer to the <<configuration-reference, Configuration Reference>>.
   ----
   
  -Then, at the end of your documentation, include the extensive documentation:
  +And at the end of the guide, the extensive configuration documentation:
   
   [source, asciidoc]
   ----
  
positive.code: quarkus.log.file.path=/tmp/debug.log
  ----
  
  Since `format` is not defined in these properties, the default value from `@ConfigItem` will be used instead.
  
  A configuration mapping name can contain an extra suffix segment for the case where there are configuration
  mappings for multiple <<Config Phases>>. Classes which correspond to the `BUILD_TIME` and `BUILD_AND_RUN_TIME_FIXED`
  
negative.code:  * @asciidoclet
   */
  // @formatter:on
  Optional<String> sqlLoadScript();
  ----
  
  For indentation to be respected in the Javadoc comment (list items spread on multiple lines or indented
  source code), the automatic Eclipse formatter must be disabled (the formatter is automatically included in the build),
  with the markers `// @formatter:off`/`// @formatter:on`. These require separate comments and a mandatory space after the
  `//` marker.
  
  [WARNING]
  ====
  Open blocks (`--`) are not supported in the Asciidoctor documentation. All the other types of blocks
  (source, admonitions...) are supported.
  ====
  
  [TIP]
  ====
  By default, the documentation generator will use the hyphenated field name as the key of a `java.util.Map`. Use the
  `io.quarkus.runtime.annotations.ConfigDocMapKey` annotation to override the behaviour.
  
  [source,java]
  ----
  @ConfigMapping(prefix = "quarkus.some")
  @ConfigRoot
  public interface SomeConfig {
      /**
       * Namespace configuration.
       */
      @WithParentName
      @ConfigDocMapKey("cache-name") // <1>
      Map<String, Name> namespace();
  }
  ----
  <1> This will generate a configuration map key named `quarkus.some."cache-name"` instead of `quarkus.some."namespace"`.
  ====
  
  ===== Writing section documentation
  
  To generate a configuration section of a given group, use the `@ConfigDocSection` annotation:
  
  [source,java]
  ----
  /**
  * Config group related configuration.
  * Amazing introduction here
  */
  @ConfigDocSection // <1>
  ConfigGroupConfig configGroup();
  ----
  <1> This will add a section documentation for the `configGroup` config item in the generated documentation. The section
  title and introduction will be derived from the javadoc of the configuration item. The first sentence from the javadoc
  is considered as the section title and the remaining sentences used as section introduction.
  
  ===== Generating the documentation
  
  To generate the documentation:
  
  * Execute `./mvnw clean install -DskipTests -DskipITs`
  * Can be executed globally or in a specific extension directory (e.g. `extensions/mailer`).
  
  The documentation is generated in the global `target/asciidoc/generated/config/` located at the root of the project.
  
  ===== Including the documentation in the extension guide
  
  To include the generated configuration reference documentation in a guide, use:
  
  [source,asciidoc]
  ----
  \include::{generated-dir}/config/quarkus-your-extension.adoc[opts=optional, leveloffset=+1]
  ----
  
  To include only a specific config group:
  [source,asciidoc]
  ----
  \include::{generated-dir}/config/hyphenated-config-group-class-name-with-runtime-or-deployment-namespace-replaced-by-config-group-namespace.adoc[opts=optional, leveloffset=+1]
  ----
  
  For example, the `io.quarkus.vertx.http.runtime.FormAuthConfig` configuration group will be generated in a file named
  `quarkus-vertx-http-config-group-form-auth-config.adoc`.
  
  A few recommendations:
  
  * `opts=optional` is mandatory to not fail the build if only part of the configuration documentation has been generated.
  * The documentation is generated with a title level of 2 (i.e. `==`). It may need an adjustment with `leveloffset=+N`.
  * The whole configuration documentation should not be included in the middle of the guide.
  
  If the guide includes an `application.properties` example, a tip must be included just below the code snippet:
  
  [source, asciidoc]
  ----
  