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:  * @asciidoclet
   */
  // @formatter:on
  @ConfigItem
  public Optional<String> sqlLoadScript;
  ----
  
  A few comments on this one:
  
   * Every time you will need the indentation to be respected in the Javadoc comment (think list items spread on multiple lines or indented source code),
     you will need to disable temporarily the automatic Eclipse formatter
     (this, even if you don't use Eclipse as the formatter is included in our build).
     To do so, use the `// @formatter:off`/`// @formatter:on` markers.
     Note the fact that they are separate comments and there is a space after the `//` marker. This is required.
   * As you can see, you can use the full power of Asciidoctor (except for the limitation below)
  
  [WARNING]
  ====
  You cannot use open blocks (`--`) in your Asciidoctor documentation.
  All the other types of blocks (source, admonitions...) are supported.
  ====
  
  [TIP]
  ====
  By default, the doc generator will use the hyphenated field name as the key of a `java.util.Map` configuration item.
  To override this default and have a user-friendly key (independent of implementation details), you may use the `io.quarkus.runtime.annotations.ConfigDocMapKey` annotation.
  See the following example,
  [source,java]
  ----
  @ConfigRoot
  public class SomeConfig {
      /**
       * Namespace configuration.
       */
      @ConfigItem(name = ConfigItem.PARENT)
      @ConfigDocMapKey("cache-name") <1>
      Map<String, CaffeineNamespaceConfig> namespace;
  }
  ----
  <1> This will generate a configuration map key named `quarkus.some."cache-name"` instead of `quarkus.some."namespace"`.
  ====
  
  === Writing section documentation
  
  If you wish to generate configuration section of a given `@ConfigGroup`, Quarkus has got you covered with the `@ConfigDocSection` annotation.
  See the code  example below:
  [source,java]
  ----
  /**
  * Config group related configuration.
  * Amazing introduction here
  */
  @ConfigItem
  @ConfigDocSection <1>
  public ConfigGroupConfig configGroup;
  ----
  <1> This will add a section documentation for the `configGroup` config item in the generated documentation.
  Section's 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.
  You can also use the `@asciidoclet` tag as shown above.
  
  === Generating the documentation
  
  Generating the documentation is easy:
  
   * Running `./mvnw clean install -DskipTests -DskipITs` will do.
   * You  can either do it 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
  
  Now that you have generated the configuration reference documentation for your extension, you need to include it in your guide (and review it).
  
  This is simple, include the generated documentation in your guide:
  
  [source,asciidoc]
  ----
  \include::{generated-dir}/config/quarkus-your-extension.adoc[opts=optional, leveloffset=+1]
  ----
  
  If you are interested in including the generated documentation for the config group, you can use the include statement below
  [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 as we don't want the build to fail if only part of the configuration documentation has been generated
   * The documentation is generated with a title level of 2 (i.e. `==`).
     You usually need to adjust it.
     It can be done with `leveloffset=+N`.
  
  It is not recommended to include the whole configuration documentation in the middle of your guide as it's heavy.
  If you have an `application.properties` extract with your configuration, just do as follows.
  
  First, include a tip just below your `application.properties` extract:
  
  [source, asciidoc]
  ----
  
negative.code: quarkus.log.file.path=/tmp/debug.log
  ----
  
  Since `format` is not defined in these properties, the default value from `@WithDefault` 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`
  