docs: fix Maven site guide page titles

micronaut-maven-plugin/src/site/asciidoc/examples/aot.adoc

@@ -1,4 +1,4 @@
-=== Using Micronaut AOT
+= Using Micronaut AOT
 
 *WARNING*: The Micronaut AOT module is in experimental stages. Use at your own risk!
 
@@ -17,7 +17,7 @@ $ mvn package -Dmicronaut.aot.enabled=true
 That integrated path continues to work through `micronaut-maven-plugin` on `5.0.x`, including the existing packaging and
 `mn:run` flows.
 
-==== Standalone AOT plugin
+== Standalone AOT plugin
 
 If a module only needs Micronaut AOT support, it can use the standalone `micronaut-maven-aot-plugin` without applying
 the main Micronaut Maven plugin:
@@ -70,7 +70,7 @@ $ mvn package -Dmicronaut.aot.enabled=true -Dpackaging=native-image
 [WARNING] Packaging is set to [native-image], but Micronaut AOT runtime is set to [jit]. Please change them so that they match
 ----
 
-==== Defining additional AOT dependencies
+== Defining additional AOT dependencies
 
 It is possible to add additional dependencies to the AOT execution classpath that may be required by some optimizations,
 or to include an external AOT optimizer (in the future, some modules such as `micronaut-security` may offer additional
@@ -105,7 +105,7 @@ as follows:
   </build>
 ----
 
-==== Configuration
+== Configuration
 
 Micronaut AOT can be configured with a `.properties` file. To get started with the possible options and their
 description, run the `aot-sample-config` goal:
@@ -126,7 +126,7 @@ directory, use the `micronaut.aot.config` property to specify its location.
 
 For a full list of configuration options, check the link:../aot-analysis-mojo.html[`aot-analysis` goal documentation].
 
-==== Excluding dependencies
+== Excluding dependencies
 
 If you want to exclude a dependency from AOT processing, use the `aotExclusions` configuration property.
 For example, to exclude `com.example:example` use the following configuration:

micronaut-maven-plugin/src/site/asciidoc/examples/bean-import.adoc

@@ -1,4 +1,4 @@
-=== Importing beans from dependencies
+= Importing beans from dependencies
 
 When project dependencies contain beans but don't contain the Micronaut bean definitions the `@Import` annotation can
 be used to import those beans and allow them to be injected in the Micronaut application context. Since this annotation

micronaut-maven-plugin/src/site/asciidoc/examples/deploy.adoc

@@ -1,4 +1,4 @@
-=== Deploying an application
+= Deploying an application
 
 Similarly to the link:package.html[packaging support], with this plugin you can use `mvn deploy` as the only command
 required to deploy an application that, depending on the `<packaging>`:

micronaut-maven-plugin/src/site/asciidoc/examples/jsonschema.adoc

@@ -1,4 +1,4 @@
-=== Integration with Micronaut JSON Schema Generator
+= Integration with Micronaut JSON Schema Generator
 
 This plugin integrates with https://micronaut-projects.github.io/micronaut-json-schema/latest/guide/[Micronaut JSON Schema] to provide support for generating beans from https://json-schema.org[JSON Schema].
 

micronaut-maven-plugin/src/site/asciidoc/examples/openapi.adoc

@@ -1,4 +1,4 @@
-=== Integration with Micronaut OpenAPI
+= Integration with Micronaut OpenAPI
 
 This plugin integrates with https://micronaut-projects.github.io/micronaut-openapi/latest/guide/index.html[Micronaut OpenAPI] to provide support for generating https://www.openapis.org/[OpenAPI] clients or servers.
 
@@ -10,7 +10,7 @@ The plugin adds a couple goals which can be used to generate code:
 In both cases, the code is generated in your `target` directory and integrated into the build lifecycle.
 In particular, in case you are generating a server, the generated code will be interfaces that you will have to implement in your main sources.
 
-==== Generating a client
+== Generating a client
 
 In order to generate a client, the minimal thing to do is to configure a couple properties:
 
@@ -39,7 +39,7 @@ It is however recommended to define the packages which will be used for code gen
 
 The full list of configuration properties can be found link:../generate-openapi-client-mojo.html[here].
 
-==== Generating a server
+== Generating a server
 
 Generating a server can be done in a similar way to generating a client, except that the code which is generated for the server (not the model) is simply interfaces that you will have to implement:
 

micronaut-maven-plugin/src/site/asciidoc/examples/package.adoc

@@ -1,4 +1,4 @@
-=== Packaging an application
+= Packaging an application
 
 This plugin supports different `<packaging>` types:
 
@@ -16,7 +16,7 @@ generated from https://micronaut.io/launch/[Micronaut Launch] have the packaging
 
 :toc:
 
-=== Packaging the application in a fat JAR
+== Packaging the application in a fat JAR
 
 ----
 $ mvn package
@@ -27,7 +27,7 @@ configuration is defined in the `io.micronaut:micronaut-parent` POM, and the def
 to customize how to produce the JAR file, refer to the
 https://maven.apache.org/plugins/maven-shade-plugin/[Maven Shade Plugin documentation].
 
-==== Classpath-sensitive libraries and shaded JARs
+=== Classpath-sensitive libraries and shaded JARs
 
 Shaded JARs are convenient for single-file deployments, but they are not a good fit for every runtime. Libraries that
 expect to discover resources, languages, or services from separate classpath entries can fail once everything is merged
@@ -125,7 +125,7 @@ Truffle's multi-release metadata. To verify the packaging, inspect `META-INF/MAN
 confirm it contains `Multi-Release: true`, then start the application with the same JDK used in production. Do not
 disable Truffle's multi-release validation check as a packaging fix.
 
-=== Generating GraalVM native images
+== Generating GraalVM native images
 
 ----
 $ mvn package -Dpackaging=native-image
@@ -162,7 +162,7 @@ For GraalVM/Java 25 or newer native images that need Netty's shared arena suppor
 `-H:+SharedArenaSupport` through the same upstream native plugin `<buildArgs>` configuration. Micronaut Maven Plugin
 does not rewrite the delegated `native-image` packaging configuration.
 
-==== Windows users
+=== Windows users
 
 Sometimes, depending on how many classes are in the classpath you may see an error `The command line is too long` when
 building a native-image. This is a https://graalvm.github.io/native-build-tools/latest/maven-plugin.html#long_classpath_and_shading_support[known issue]
@@ -211,7 +211,7 @@ mvn package -Dpackaging=native-image # <2>
 <1> Create the shaded runnable jar for the application.
 <2> Use the shaded runnable jar to build the native image.
 
-=== Building daemonless native executable container images
+== Building daemonless native executable container images
 
 ----
 $ mvn package -Dpackaging=native-image -Dmicronaut.native-image.jib.enabled=true
@@ -263,7 +263,7 @@ executable from another host OS. If you have intentionally cross-compiled a comp
 
 Lambda and Oracle Function native images keep their existing runtime-specific `docker-native` packaging paths.
 
-=== Building JVM-based Docker images
+== Building JVM-based Docker images
 
 ----
 $ mvn package -Dpackaging=docker
@@ -320,7 +320,7 @@ For example, you can define the `jib-maven-plugin` in your POM as follows to pas
 </plugin>
 ----
 
-=== Delegating packaging to Eclipse JKube
+== Delegating packaging to Eclipse JKube
 
 ----
 $ mvn package -Dpackaging=k8s
@@ -372,7 +372,7 @@ and package with:
 mvn package -Dpackaging=openshift
 ----
 
-=== Bringing your own `Dockerfile`
+== Bringing your own `Dockerfile`
 
 ----
 $ mvn package -Dpackaging=docker
@@ -397,7 +397,7 @@ COPY dependency/* /home/app/libs/
 ENTRYPOINT ["java", "-cp", "/home/app/libs/*:/home/app/classes/", "com.example.app.Application"]
 ----
 
-=== Building GraalVM-based Docker images
+== Building GraalVM-based Docker images
 
 ----
 $ mvn package -Dpackaging=docker-native
@@ -441,7 +441,7 @@ $ mvn package -Dpackaging=docker-native \
 Prefer passing credential-bearing proxy values from the command line or CI secrets rather than committing them to
 the project POM.
 
-==== Bringing your own native `Dockerfile`
+=== Bringing your own native `Dockerfile`
 
 ----
 $ mvn package -Dpackaging=docker-native
@@ -599,7 +599,7 @@ Or from the command line:
 $ mvn package -Dpackaging=docker-native -Dmicronaut.native-image.args="--verbose"
 ----
 
-=== Building CRaC-based Docker images
+== Building CRaC-based Docker images
 
 **Warning**: The Micronaut CRaC module is in experimental stages. Use at your own risk!
 
@@ -630,7 +630,7 @@ https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#configu
 * The base image, using `<from><image>`.
 * The image name/tags that will be used for building, using either `<to><image>` and/or `<to><tags>`.
 
-==== Checking an application is ready
+=== Checking an application is ready
 
 As part of the checkpointing process, the application will be tested until it is ready to receive requests.
 This is by default done by executing the command `curl --output /dev/null --silent --head http://localhost:8080`, however you can override this by setting the `crac.readiness` property in your build.
@@ -643,7 +643,7 @@ This is by default done by executing the command `curl --output /dev/null --sile
 </properties>
 ----
 
-==== Customizing warmup
+=== Customizing warmup
 
 The default warmup script simply makes a request to port 8080 of the application.
 However, you can specify your own by placing a Bash script named `warmup.sh` in the root project folder.
@@ -659,7 +659,7 @@ for run in {1..10}; do
 done
 ----
 
-==== Customizing the JDK
+=== Customizing the JDK
 
 By default, the CRaC JDK used to build the image will be for the current system architecture and Java 25.
 These can be overridden by passing properties to the build:

micronaut-maven-plugin/src/site/asciidoc/examples/run.adoc

@@ -1,4 +1,4 @@
-=== Running an application in development mode
+= Running an application in development mode
 
 It watches for changes in the project tree, and if they match certain conditions, it will recompile and restart the
 application.
@@ -10,7 +10,7 @@ deals with file changes and JVM restarts.
 
 :toc:
 
-=== Usage
+== Usage
 
 You can use `mn:run` to run your application in development mode:
 
@@ -35,7 +35,7 @@ $ mvn clean mn:run
 13:36:32.665 [main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 919ms. Server Running: http://localhost:8080
 ----
 
-==== Including and excluding options
+=== Including and excluding options
 
 By default, this plugin watches for changes in the following locations:
 
@@ -84,7 +84,7 @@ Note that exclusions take precedence over inclusions, so if a file change matche
 
 When no `includes/excludes` rules are specified, a `\**/*` pattern will be included by default.
 
-==== Debugging
+=== Debugging
 
 Debugging options can be specified on the command line directly:
 
@@ -93,11 +93,11 @@ Debugging options can be specified on the command line directly:
 * Changing the debugger host: `mvn mn:run -Dmn.debug -Dmn.debug.host=192.168.1.8` or `mvn mn:run -Dmn.debug -Dmn.debug.host=*`
 * Suspending the debugger execution: `mn:run -Dmn.debug -Dmn.debug.suspend`.
 
-==== Other options
+=== Other options
 
 For a full list of configuration options, check the link:../run-mojo.html[mn:run] goal documentation.
 
-==== Collecting native-image metadata during `mn:run`
+=== Collecting native-image metadata during `mn:run`
 
 `mn:run` can launch the application with the GraalVM native-image tracing agent by using the same `-Dagent=true`
 switch that `org.graalvm.buildtools:native-maven-plugin` understands:

micronaut-maven-plugin/src/site/asciidoc/examples/test-resources.adoc

@@ -1,4 +1,4 @@
-=== Integration with Micronaut Test Resources
+= Integration with Micronaut Test Resources
 
 https://micronaut-projects.github.io/micronaut-test-resources/latest/guide/index.html[Micronaut Test Resources] adds
 support for managing external resources which are required during development or testing. In particular, it integrates
@@ -33,7 +33,7 @@ configuration properties will automatically be injected to your application.
 Please refer to the https://micronaut-projects.github.io/micronaut-test-resources/latest/guide/index.html[Micronaut Test
 Resources documentation] for a list of all supported modules and their configuration options.
 
-==== Standalone Test Resource Service
+== Standalone Test Resource Service
 
 The default behaviour works particularly well in single-module projects, or in multi-module projects where test resources
 are not shared between modules. However, in some cases, you may want to reuse test containers for multiple projects of
@@ -52,7 +52,7 @@ However, you might want to run the consumer in one terminal, and the producer in
 the same Kafka cluster. For this you can use a shared test server, by passing the `micronaut.test.resources.shared`
 system property, or setting `<shared>true</shared>` in the Micronaut Maven Plugin configuration.
 
-==== Test Resource Service lifecycle
+== Test Resource Service lifecycle
 
 Test resources are handled by a service which is, by default, started at the beginning of a build, and stopped at the end.
 
@@ -76,7 +76,7 @@ $ mvn mn:run
 Then the test resources will be spawned before the application starts, and shutdown when you Ctrl+C the `mn:run`
 execution.
 
-==== Keeping the Test Resources Service alive
+== Keeping the Test Resources Service alive
 
 If you want to start the test resources service in the background, and keep it alive for multiple, independent builds
 (different invocations on the command line for example), you can run the `mn:start-testresources-service` goal:
@@ -106,7 +106,7 @@ $ mvn mn:start-testresources-service
 
 To stop it, use the `mn:stop-testresources-service` goal.
 
-==== Adding modules or libraries to the Test Resources service classpath
+== Adding modules or libraries to the Test Resources service classpath
 
 If not using classpath inference, or when the inference doesn't produce the desired result, you can add dependencies
 to the Test Resources service classpath with a `<testResourcesDependencies>` block.
@@ -141,7 +141,7 @@ it like this:
 
 The versions of those dependencies will be resolved against the Micronaut BOM.
 
-==== Using a sibling reactor module for custom resolvers
+== Using a sibling reactor module for custom resolvers
 
 If you want to implement a custom `TestResourcesResolver` in the same multi-module Maven build as the application which
 uses it, put the resolver in a dedicated sibling module and add that module to `<testResourcesDependencies>` in the
@@ -218,7 +218,7 @@ reactor and the plugin adds that artifact to the Test Resources service classpat
 The list of supported modules is described in the
 https://micronaut-projects.github.io/micronaut-test-resources/latest/guide/#modules[Micronaut Test Resources documentation].
 
-==== Additional configuration options
+== Additional configuration options
 
 You can see all the additional configuration options in the
 link:../start-testresources-service-mojo.html[`start-testresources-service` goal documentation].

micronaut-maven-plugin/src/site/asciidoc/release-history.adoc

@@ -1,3 +1,3 @@
-=== Release History
+= Release History
 
-To see the release history, check the https://github.com/micronaut-projects/micronaut-maven-plugin/releases[GitHub Releases] page.
+To see the release history, check the https://github.com/micronaut-projects/micronaut-maven-plugin/releases[GitHub Releases] page.