diff --git a/docs/src/main/asciidoc/_project-features-contract.adoc b/docs/src/main/asciidoc/_project-features-contract.adoc
index ef73b5c5f0..0d293f64b9 100644
--- a/docs/src/main/asciidoc/_project-features-contract.adoc
+++ b/docs/src/main/asciidoc/_project-features-contract.adoc
@@ -479,7 +479,9 @@ include::{contract_kotlin_spec_path}/src/test/kotlin/org/springframework/cloud/c
 
 In the following sections you can find examples of the supported metadata entries.
 
+////
 include::{project-root}/docs/target/metadata.adoc[indent=0]
+////
 
 [[features-http]]
 == Contracts for HTTP
diff --git a/docs/src/main/asciidoc/_project-features-stubrunner.adoc b/docs/src/main/asciidoc/_project-features-stubrunner.adoc
index ec66a0a7d2..81b045fbdb 100644
--- a/docs/src/main/asciidoc/_project-features-stubrunner.adoc
+++ b/docs/src/main/asciidoc/_project-features-stubrunner.adoc
@@ -16,6 +16,7 @@ You can add the additional snapshot repository to your build file to use snapsho
 versions, which are automatically uploaded after every successful build, as follows:
 
 ====
+////
 [source,xml,indent=0,subs="verbatim,attributes",role="primary"]
 .Maven
 ----
@@ -27,6 +28,7 @@ include::{standalone_samples_path}/http-server/pom.xml[tags=repos,indent=0]
 ----
 include::{standalone_samples_path}/http-server/build.gradle[tags=repos,indent=0]
 ----
+////
 ====
 
 [[features-stub-runner-publishing-stubs-as-jars]]
@@ -41,6 +43,7 @@ it if you want to.
 The following example shows how to publish stubs as jars:
 
 ====
+////
 [source,xml,indent=0,subs="verbatim,attributes",role="primary"]
 .Maven
 ----
@@ -53,12 +56,15 @@ include::{samples_url}/producer_with_restdocs/pom.xml[tags=assembly,indent=0]
 <!-- Finally setup your assembly. Below you can find the contents of src/main/assembly/stub.xml -->
 include::{samples_url}/producer_with_restdocs/src/assembly/stub.xml[indent=0]
 ----
+////
 
+////
 [source,groovy,indent=0,subs="verbatim,attributes",role="secondary"]
 .Gradle
 ----
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/scenarioProject/build.gradle[tags=jar_setup,indent=0]
 ----
+////
 ====
 
 [[features-stub-runner-core]]
@@ -244,19 +250,23 @@ example shows how to do so:
 
 .WireMockHttpServerStubConfigurer implementation
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/StubRunnerConfigurationSpec.groovy[tags=wireMockHttpServerStubConfigurer]
 ----
+////
 ====
 
 You can then reuse it with the `@AutoConfigureStubRunner` annotation, as follows:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/StubRunnerConfigurationSpec.groovy[tags=annotation]
 ----
+////
 ====
 
 Whenever an HTTPS port is found, it takes precedence over the HTTP port.
@@ -372,10 +382,12 @@ Stub Runner comes with a JUnit rule that lets you can download and run stubs for
 group and artifact ID, as the following example shows:
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/junit4/StubRunnerRuleJUnitTest.java[tags=classrule]
 ----
+////
 ====
 
 A `StubRunnerExtension` is also available for JUnit 5. `StubRunnerRule` and
@@ -398,15 +410,18 @@ Since the `StubRunnerRule` and `StubRunnerExtension` implement the `StubFinder`,
 you find the started stubs, as the following example shows:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/main/java/org/springframework/cloud/contract/stubrunner/StubFinder.java[lines=16..-1]
 ----
+////
 ====
 
 The following examples provide more detail about using Stub Runner:
 
 ====
+////
 [source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
 .Spock
 ----
@@ -424,6 +439,7 @@ include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contra
 ----
 include::{stubrunner_core_path}/src/test/java/org/springframework/cloud/contract/stubrunner/junit/StubRunnerJUnit5ExtensionTests.java[tags=extension]
 ----
+////
 ====
 
 See the <<features-stub-runner-common-properties-junit-spring>> for more information on
@@ -454,19 +470,23 @@ When using the `StubRunnerRule` or `StubRunnerExtension`, you can add a stub to
 and then pass the port for the last downloaded stub. The following example shows how to do so:
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/junit4/StubRunnerRuleCustomPortJUnitTest.java[tags=classrule_with_port]
 ----
+////
 ====
 
 For the preceding example, the following test is valid:
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/junit4/StubRunnerRuleCustomPortJUnitTest.java[tags=test_with_port]
 ----
+////
 ====
 
 [[features-stub-runner-rule-spring]]
@@ -481,29 +501,35 @@ If you want to find the URL of your stubbed dependency, you can autowire the `St
 its methods, as follows:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/StubRunnerConfigurationSpec.groovy[tags=test]
 ----
+////
 ====
 
 Doing so depends on the following configuration file:
 
 ====
+////
 [source,yml,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/resources/application-test.yml[tags=test]
 ----
+////
 ====
 
 Instead of using the properties, you can also use the properties inside the `@AutoConfigureStubRunner`.
 The following example achieves the same result by setting values on the annotation:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerSpringCloudAutoConfigurationSpec.groovy[tags=autoconfigure]
 ----
+////
 ====
 
 Stub Runner Spring registers environment variables in the following manner
@@ -559,19 +585,23 @@ instead of calling the real Service Discovery tool.
 For example, the following test passes:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerSpringCloudAutoConfigurationSpec.groovy[tags=test]
 ----
+////
 ====
 
 Note that the preceding example requires the following configuration file:
 
 ====
+////
 [source,yml,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/resources/application.yml[tags=ids]
 ----
+////
 ====
 
 [[features-stub-runner-cloud-stubbing-profiles]]
@@ -709,10 +739,12 @@ For Messaging, Stub Runner Boot makes the following endpoints available:
 
 The following example shows typical usage of Stub Runner Boot:
 
+////
 [source,groovy,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/server/StubRunnerBootSpec.groovy[tags=boot_usage]
 ----
+////
 
 [[features-stub-runner-boot-service-discovery]]
 ==== Stub Runner Boot with Service Discovery
@@ -731,10 +763,12 @@ required stubs and registering them in a service discovery tool. Consider the fo
 such a setup with Eureka (assume that Eureka is already running):
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/serverexamples/StubRunnerBootEurekaExample.java[tags=stubrunnereureka]
 ----
+////
 ====
 
 We want to start a Stub Runner Boot server (`@EnableStubRunnerServer`), enable the Eureka client (`@EnableEurekaClient`),
@@ -745,10 +779,12 @@ We can do so by running the application with `java -jar ${SYSTEM_PROPS} stub-run
 `${SYSTEM_PROPS}` contains the following list of properties:
 
 ====
+////
 [source,bash,indent=0]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/serverexamples/StubRunnerBootEurekaExample.java[tags=stubrunnereureka_args]
 ----
+////
 ====
 
 That way, your deployed application can send requests to started WireMock servers through service
@@ -826,12 +862,14 @@ The `bar-consumer` consumer can either set the `spring.application.name` or the
 Alternatively, you can set the test as follows:
 
 ====
+////
 [source,groovy]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerStubsPerConsumerSpec.groovy[tags=test]
 ...
 }
 ----
+////
 ====
 
 Then only the stubs registered under a path that contains `bar-consumer` in its name (that is, those from the
@@ -840,12 +878,14 @@ Then only the stubs registered under a path that contains `bar-consumer` in its
 You can also set the consumer name explicitly, as follows:
 
 ====
+////
 [source,groovy]
 ----
 include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerStubsPerConsumerWithConsumerNameSpec.groovy[tags=test]
 ...
 }
 ----
+////
 ====
 
 Then only the stubs registered under a path that contains the `foo-consumer` in its name (that is, those from the
diff --git a/docs/src/main/asciidoc/getting-started.adoc b/docs/src/main/asciidoc/getting-started.adoc
index 7d061ae6a2..9c551ad047 100644
--- a/docs/src/main/asciidoc/getting-started.adoc
+++ b/docs/src/main/asciidoc/getting-started.adoc
@@ -117,17 +117,21 @@ the `PUT` method. The following listing shows a contract to check whether a clie
 be marked as a fraud in both Groovy and YAML:
 
 ====
+////
 [source,groovy,indent=0,role="primary"]
 .groovy
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]
 ----
+////
 
+////
 [source,yaml,indent=0,role="secondary"]
 .yaml
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[]
 ----
+////
 ====
 
 [[getting-started-three-second-tour]]
@@ -173,10 +177,12 @@ Then you can add the Spring Cloud Contract Verifier dependency and plugin to you
 the following example shows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
 ----
+////
 ====
 
 The following listing shows how to add the plugin, which should go in the build/plugins
@@ -249,10 +255,12 @@ To do so, add the dependency to `Spring Cloud Contract Stub Runner`, as the
 following example shows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
 ----
+////
 ====
 
 You can get the Producer-side stubs installed in your Maven repository in either of two
@@ -277,10 +285,12 @@ pass the stub artifact IDs and artifact repository URL as `Spring Cloud Contract
 Stub Runner` properties, as the following example shows:
 +
 ====
+////
 [source,yaml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]
 ----
+////
 ====
 
 Now you can annotate your test class with `@AutoConfigureStubRunner`. In the annotation,
@@ -330,10 +340,12 @@ To start working with `Spring Cloud Contract`, you can add the Spring Cloud Cont
 dependency and plugin to your build file, as the following example shows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
 ----
+////
 ====
 
 The following listing shows how to add the plugin, which should go in the build/plugins
@@ -745,10 +757,12 @@ WireMock instance or messaging route that simulates the actual service.
 To get started, add the dependency to `Spring Cloud Contract Stub Runner`, as follows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
 ----
+////
 ====
 
 You can get the Producer-side stubs installed in your Maven repository in either of two
@@ -772,10 +786,12 @@ pass the stub artifact IDs and artifact repository URL as `Spring Cloud Contract
 Runner` properties, as the following example shows:
 +
 ====
+////
 [source,yaml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]
 ----
+////
 ====
 
 Now you can annotate your test class with `@AutoConfigureStubRunner`. In the annotation,
@@ -852,17 +868,21 @@ If you use the SNAPSHOT, Milestone, or Release Candidate versions, you need to a
 following section to your build:
 
 ====
+////
 [source,xml,indent=0,subs="verbatim,attributes",role="primary"]
 .Maven
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=repos,indent=0]
 ----
+////
 
+////
 [source,groovy,indent=0,subs="verbatim,attributes",role="secondary"]
 .Gradle
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/build.gradle[tags=deps_repos,indent=0]
 ----
+////
 ====
 
 For simplicity, we use the following acronyms:
@@ -926,10 +946,12 @@ The following listing shows a test that we might use to check whether a loan amo
 large:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=client_tdd,indent=0]
 ----
+////
 ====
 
 Assume that you have written a test of your new feature. If a loan application for a big
@@ -944,10 +966,12 @@ client wants to borrow. You want to send it to the `/fraudcheck` URL by using th
 To do so, you might use code similar to the following:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/src/main/java/com/example/loan/LoanApplicationService.java[tags=client_call_server,indent=0]
 ----
+////
 ====
 
 For simplicity, the port of the Fraud Detection service is set to `8080`, and the
@@ -981,17 +1005,21 @@ is important because the producer's test base class name references that folder.
 The following example shows our contract, in both Groovy and YAML:
 
 ====
+////
 [source,groovy,indent=0,role="primary"]
 .groovy
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]
 ----
+////
 
+////
 [source,yaml,indent=0,role="secondary"]
 .yaml
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[]
 ----
+////
 ====
 
 The YML contract is quite straightforward. However, when you take a look at the contract
@@ -1029,19 +1057,23 @@ We can add either a Maven or a Gradle plugin. In this example, we show how to ad
 First, we add the `Spring Cloud Contract` BOM, as the following example shows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_bom,indent=0]
 ----
+////
 ====
 
 Next, add the `Spring Cloud Contract Verifier` Maven plugin, as the following example shows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
 ----
+////
 ====
 
 Since the plugin was added, you get the `Spring Cloud Contract Verifier` features, which,
@@ -1103,19 +1135,23 @@ Application service`):
 . Add the `Spring Cloud Contract` BOM, as follows:
 +
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=contract_bom,indent=0]
 ----
+////
 ====
 
 . Add the dependency to `Spring Cloud Contract Stub Runner`, as follows:
 +
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
 ----
+////
 ====
 
 . Annotate your test class with `@AutoConfigureStubRunner`. In the annotation, provide the
@@ -1123,10 +1159,12 @@ include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub
 collaborators.
 +
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=autoconfigure_stubrunner,indent=0]
 ----
+////
 ====
 
 .  (Optional) Because you are playing with the collaborators offline, you
@@ -1199,12 +1237,14 @@ The following UML diagram shows the fraud detection flow:
 As a reminder, the following listing shows the initial implementation:
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0]
 include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0]
 }
 ----
+////
 ====
 
 Then you can run the following commands:
@@ -1220,19 +1260,23 @@ $ git pull https://your-git-server.com/server-side-fork.git contract-change-pr
 You must add the dependencies needed by the autogenerated tests, as follows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
 ----
+////
 ====
 
 In the configuration of the Maven plugin, you must pass the `packageWithBaseClasses` property, as follows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
 ----
+////
 ====
 
 IMPORTANT: This example uses "`convention-based`" naming by setting the
@@ -1248,10 +1292,12 @@ start the server side `FraudDetectionController`. The following listing shows th
 `FraudBase` class:
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/test/java/com/example/fraud/FraudBase.java[]
 ----
+////
 ====
 
 Now, if you run the `./mvnw clean install`, you get something like the following output:
@@ -1312,6 +1358,7 @@ Because you know the expected input and expected output, you can write the missi
 implementation as follows:
 
 ====
+////
 [source,java,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0]
@@ -1319,6 +1366,7 @@ include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com
 include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0]
 }
 ----
+////
 ====
 
 When you run `./mvnw clean install` again, the tests pass. Since the Spring Cloud
@@ -1392,10 +1440,12 @@ side are automatically downloaded from Nexus/Artifactory. You can set the value
 achieving the same thing by changing the properties:
 
 ====
+////
 [source,yaml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]
 ----
+////
 ====
 
 That's it. You have finished the tutorial.
diff --git a/docs/src/main/asciidoc/gradle-project.adoc b/docs/src/main/asciidoc/gradle-project.adoc
index d7f70f4fd5..654b6d47a4 100644
--- a/docs/src/main/asciidoc/gradle-project.adoc
+++ b/docs/src/main/asciidoc/gradle-project.adoc
@@ -174,11 +174,13 @@ You can add the additional snapshot repository to your `settings.gradle` to use
 which are automatically uploaded after every successful build, as the following listing shows:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{standalone_samples_path}/http-server/settings.gradle[tags=repos,indent=0]
 }
 ----
+////
 ====
 
 [[gradle-add-stubs]]
@@ -400,10 +402,12 @@ specification for all generated acceptance tests. In this class, you need to poi
 endpoint, which should be verified. The following example shows how to do so:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/bootSimple/src/test/groovy/org/springframework/cloud/contract/verifier/twitter/places/BaseMockMvcSpec.groovy[tags=base_class,indent=0]
 ----
+////
 ====
 
 If you use `Explicit` mode, you can use a base class to initialize the whole tested application,
@@ -431,10 +435,12 @@ forms a class with a `Base` suffix. This rule takes precedence over `baseClassFo
 The following example shows how it works in the `contracts` closure:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/groovy/org/springframework/cloud/contract/verifier/plugin/ContractVerifierSpec.groovy[tags=package_with_base_classes,indent=0]
 ----
+////
 ====
 
 === By Mapping
@@ -445,10 +451,12 @@ name of the base class for the matched contract. You have to provide a list call
 `contractPackageRegex` to `baseClassFQN` mapping. Consider the following example:
 
 ====
+////
 [source,groovy,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/groovy/org/springframework/cloud/contract/verifier/plugin/ContractVerifierSpec.groovy[tags=base_class_mappings,indent=0]
 ----
+////
 ====
 
 Assume that you have contracts in the following directories:
diff --git a/docs/src/main/asciidoc/howto.adoc b/docs/src/main/asciidoc/howto.adoc
index 452623925a..21ef0481e9 100644
--- a/docs/src/main/asciidoc/howto.adoc
+++ b/docs/src/main/asciidoc/howto.adoc
@@ -290,10 +290,12 @@ one-to-one to the contents of the repository.
 The following example shows a `pom.xml` file inside the `server` folder:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/contracts/com/example/server/pom.xml[indent=0]
 ----
+////
 ====
 
 There are no dependencies other than the Spring Cloud Contract Maven Plugin.
@@ -303,20 +305,24 @@ the stubs of the producer project.
 The `pom.xml` file in the root folder can look like the following:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/contracts/pom.xml[indent=0]
 ----
+////
 ====
 
 It uses the assembly plugin to build the JAR with all the contracts. The following example
 shows such a setup:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/samples/standalone/contracts/src/assembly/contracts.xml[indent=0]
 ----
+////
 ====
 
 [[how-to-workflow]]
@@ -379,10 +385,12 @@ As a producer, you can alter the Spring Cloud Contract Verifier to provide the U
 the dependency of the JAR that contains the contracts, as follows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{introduction_url}/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/src/test/projects/basic-remote-contracts/pom-with-repo.xml[tags=remote_config,indent=0]
 ----
+////
 ====
 
 With this setup, the JAR with a `groupid` of `com.example.standalone` and an `artifactid` of
@@ -770,6 +778,7 @@ contracts locally, with the producer, and only push the contracts and the stubs
 The following listing shows the setup required to achieve this with Maven and Gradle:
 
 ====
+////
 [source,xml,indent=0,role="primary"]
 .Maven
 ----
@@ -781,6 +790,7 @@ include::{samples_url}/producer_with_empty_git/pom.xml[tags=plugin,indent=0]
 ----
 include::{samples_url}/producer_with_empty_git/build.gradle[tags=plugin,indent=0]
 ----
+////
 ====
 
 With such a setup:
@@ -875,10 +885,12 @@ Spring Cloud Contract can read the Pact JSON definition. You can place the file
 `src/test/resources/contracts` folder. Remember to put the `spring-cloud-contract-pact` dependency to your classpath. The following example shows such a Pact contract:
 
 ====
+////
 [source,javascript,indent=0]
 ----
 include::{standalone_pact_path}/http-server/src/test/resources/contracts/pact/shouldMarkClientAsFraud.json[indent=0]
 ----
+////
 ====
 
 [[how-to-use-pact-broker-pact-for-producers]]
@@ -890,6 +902,7 @@ the current Pact version that you use. The following listing shows how to do so
 Maven and Gradle:
 
 ====
+////
 [source,xml,indent=0,subs="verbatim,attributes",role="primary"]
 .Maven
 ----
@@ -901,6 +914,7 @@ include::{standalone_pact_path}/http-server/pom.xml[tags=pact_dependency,indent=
 ----
 include::{standalone_pact_path}/http-server/build.gradle[tags=pact_dependency,indent=0]
 ----
+////
 ====
 
 When you build your application, a test and stub is generated. The following
@@ -973,6 +987,7 @@ current Pact version that you use. The following listing shows how to do so for
 Maven and Gradle:
 
 ====
+////
 [source,xml,indent=0,subs="verbatim,attributes",role="primary"]
 .Maven
 ----
@@ -984,6 +999,7 @@ include::{standalone_pact_path}/http-client/pom.xml[tags=pact_dependency,indent=
 ----
 include::{standalone_pact_path}/http-client/build.gradle[tags=pact_dependency,indent=0]
 ----
+////
 ====
 
 [[pact-stub-downloader]]
@@ -1432,6 +1448,7 @@ you only need to make some minor changes to your setup if you are using MockMvc
 To do so, include the following dependencies (if you have not already done so):
 
 ====
+////
 [source,xml,indent=0,subs="verbatim,attributes",role="primary"]
 .maven
 ----
@@ -1443,12 +1460,14 @@ include::{standalone_restdocs_path}/http-server/pom.xml[tags=dependencies,indent
 ----
 include::{standalone_restdocs_path}/http-server/build.gradle[tags=dependencies,indent=0]
 ----
+////
 ====
 
 Next, you need to make some changes to your base class. The following examples use
 `WebAppContext` and the standalone option with RestAssured:
 
 ====
+////
 [source,java,indent=0,subs="verbatim,attributes",role="primary"]
 .WebAppContext
 ----
@@ -1460,6 +1479,7 @@ include::{standalone_restdocs_path}/http-server/src/test/java/com/example/fraud/
 ----
 include::{standalone_restdocs_path}/http-server/src/test/java/com/example/fraud/FraudBaseWithStandaloneSetup.java[tags=base_class,indent=0]
 ----
+////
 ====
 
 TIP: You need not specify the output directory for the generated snippets (since version 1.2.0.RELEASE of Spring REST Docs).
diff --git a/docs/src/main/asciidoc/maven-project.adoc b/docs/src/main/asciidoc/maven-project.adoc
index 00970bef31..58d36c1d9f 100644
--- a/docs/src/main/asciidoc/maven-project.adoc
+++ b/docs/src/main/asciidoc/maven-project.adoc
@@ -25,19 +25,23 @@ You can also check the plugin's documentation link:../../spring-cloud-contract-m
 To add the Spring Cloud Contract BOM, include the following section in your `pom.xml` file:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{standalone_samples_path}/http-server/pom.xml[tags=contract_bom,indent=0]
 ----
+////
 ====
 
 Next, add the `Spring Cloud Contract Verifier` Maven plugin, as follows:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{standalone_samples_path}/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
 ----
+////
 ====
 
 You can read more in the
@@ -137,10 +141,12 @@ To use Snapshot and Milestone versions, you have to add the following section to
 `pom.xml`:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{standalone_samples_path}/http-server/pom.xml[tags=repos,indent=0]
 ----
+////
 ====
 
 [[maven-add-stubs]]
@@ -394,10 +400,12 @@ forms a class with a `Base` suffix. This rule takes precedence over `baseClassFo
 The following example shows how it works in the `contracts` closure:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-maven-plugin/src/test/projects/basic-generated-baseclass/pom.xml[tags=convention,indent=0]
 ----
+////
 ====
 
 === By Mapping
@@ -408,10 +416,12 @@ name of the base class for the matched contract. You have to provide a list call
 `contractPackageRegex` to `baseClassFQN` mapping. Consider the following example:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-maven-plugin/src/test/projects/basic-baseclass-from-mappings/pom.xml[tags=mapping,indent=0]
 ----
+////
 ====
 
 Assume that you have contracts under these two locations:
@@ -641,10 +651,12 @@ path where your base test classes are defined and the path were the generated co
 The following example shows how to do so:
 
 ====
+////
 [source,xml,indent=0]
 ----
 include::{samples_url}/producer_with_spock/pom.xml[tags=gmavenplus-setup,indent=0]
 ----
+////
 ====
 
 If you uphold the Spock convention of ending the test class names with `Spec`, you also need to adjust your Maven
diff --git a/docs/src/main/asciidoc/yml-schema.adoc b/docs/src/main/asciidoc/yml-schema.adoc
index 0bae1f161d..e2fb46935a 100644
--- a/docs/src/main/asciidoc/yml-schema.adoc
+++ b/docs/src/main/asciidoc/yml-schema.adoc
@@ -5,8 +5,10 @@ include::_attributes.adoc[]
 Below you can find a JSON schema definition of a YAML contract.
 
 ====
+////
 [source,json,indent=0]
 ----
 include::{project-root}/docs/target/contract_schema.json[indent=0]
 ----
+////
 ====