Insert explicit ids for headers

docs/modules/ROOT/pages/README.adoc

@@ -1,3 +1,4 @@
+[[spring-cloud-contract]]
 == Spring Cloud Contract
 
 You always need confidence when pushing new features into a new application or service in
@@ -6,10 +7,12 @@ contracts and service schemas in Spring applications, covering a range of option
 writing tests, publishing them as assets, and asserting that a contract is kept by
 producers and consumers -- for both HTTP and message-based interactions.
 
+[[project-page]]
 == Project page
 
 You can read more about Spring Cloud Contract by going to https://spring.io/projects/spring-cloud-contract[the project page]
 
+[[contributing]]
 == Contributing
 
 include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/docs/src/main/asciidoc/contributing.adoc[]

docs/modules/ROOT/pages/_building.adoc

@@ -1,5 +1,7 @@
+[[how-to-build-spring-cloud-contract]]
 == How to Build Spring Cloud Contract
 
+[[cloning-the-repository-on-windows]]
 === Cloning the repository on Windows
 
 While cloning this project on Windows, some files in the git repository may exceed the Windows maximum file path limit of 255 characters, which may
@@ -43,6 +45,7 @@ have Docker installed.
 
 IMPORTANT: If you want to run the build in offline mode, you must have Maven 3.5.2+ installed.
 
+[[project-structure]]
 === Project structure
 
 The following listing shows the Spring Cloud Contract folder structure:
@@ -82,6 +85,7 @@ The following list describes each of the top-level folders in the project struct
 - `spring-cloud-contract-wiremock`: All WireMock related functionality
 - `tests`: Integration tests for different messaging technologies
 
+[[commands]]
 === Commands
 
 To build the core functionality together with the Maven Plugin, you can run the following
@@ -102,6 +106,7 @@ cd spring-cloud-contract-tools/spring-cloud-contract-gradle-plugin
 ./gradlew clean build
 ```
 
+[[helpful-scripts]]
 === Helpful scripts
 
 We provide a couple of helpful scripts to build the project.

docs/modules/ROOT/pages/_configprops.adoc

@@ -44,4 +44,4 @@
 |wiremock.server.port-dynamic | `+++false+++` | 
 |wiremock.server.stubs | `+++[]+++` | 
 
-|===
+|===

docs/modules/ROOT/pages/_index_single.adoc

@@ -14,4 +14,4 @@ include::gradle-project.adoc[leveloffset=+1]
 include::docker-project.adoc[leveloffset=+1]
 include::advanced.adoc[leveloffset=+1]
 include::howto.adoc[leveloffset=+1]
-include::appendix.adoc[leveloffset=+1]
+include::appendix.adoc[leveloffset=+1]

docs/modules/ROOT/pages/_project-features-contract.adoc

@@ -1385,6 +1385,7 @@ contract.
 Currently, Spring Cloud Contract Verifier supports only JSON path-based matchers with the
 following matching possibilities:
 
+[[coded-dsl]]
 ===== Coded DSL
 
 For the stubs (in tests on the consumer's side):
@@ -1430,6 +1431,7 @@ following, depending on the JSON path:
 ** `Boolean`: If you point to a `Boolean`.
 * `byNull()`: The value taken from the response in the provided JSON path must be null.
 
+[[yaml]]
 ===== YAML
 
 NOTE: See the Groovy section for a detailed explanation of
@@ -1850,6 +1852,7 @@ public void validate_xmlMatches() throws Exception {
 ----
 ====
 
+[[xml-support-for-namespaces]]
 ==== XML Support for Namespaces
 Namespaced XML is supported. However, any XPath expresssions used to select namespaced content must be updated.
 
@@ -1881,6 +1884,7 @@ The XPath expression to select the email address is
 WARNING: Beware, as the unqualified expressions (`/customer/email/text()` or `*/[local-name()='customer' and namespace-uri()='http://demo.com/customer']/email/text()`)
 result in `""`. Even the child elements have to be referenced with the `local-name` syntax.
 
+[[general-namespaced-node-expression-syntax]]
 ===== General Namespaced Node Expression Syntax
 - Node using qualified namespace:
 ```

docs/modules/ROOT/pages/appendix.adoc

@@ -11,10 +11,12 @@ This appendix provides a list of common {project-full-name} properties and refer
 NOTE: Property contributions can come from additional jar files on your classpath, so you should not consider this an exhaustive list.
 Also, you can define your own properties.
 
+[[default-application-properties]]
 === Default application properties
 
 include::_configprops.adoc[]
 
+[[additional-application-properties]]
 === Additional application properties
 
-include::_additional-stubrunner-configprops.adoc[]
+include::_additional-stubrunner-configprops.adoc[]

docs/modules/ROOT/pages/documentation-overview.adoc

@@ -57,6 +57,7 @@ If you are getting started with {project-full-name} or 'Spring' in general, star
 
 
 
+[[working-with-{project-full-name}]]
 == Working with {project-full-name}
 Ready to actually start using {project-full-name}? <<using.adoc#using, We have
 you covered>>:
@@ -84,6 +85,7 @@ play a vital role in the process of creating the contracts. We recommended this
 to implement when both producer and consumer teams work for the same organizations and the number
 of consumers is not extremely large.
 
+[[learning-about-{project-full-name}-features]]
 == Learning about {project-full-name} Features
 Need more details about {project-full-name}'s core features?
 <<project-features.adoc#features, The following content is for you>>:
@@ -106,6 +108,7 @@ link:gradle-project.html[Contract Verifier - Gradle] |
 link:docker-project.html[Docker]
 
 
+[[advanced-topics]]
 == Advanced Topics
 Finally, we have a few topics for more advanced users:
 

docs/modules/ROOT/pages/gradle-project.adoc

@@ -1,3 +1,4 @@
+[[gradle-project]]
 = Gradle Project
 include::_attributes.adoc[]
 
@@ -420,6 +421,7 @@ plugin which class should get extended by the autogenerated tests. You have two
 * Follow a convention by providing the `packageWithBaseClasses`
 * Provide explicit mapping by using `baseClassMappings`
 
+[[by-convention]]
 === By Convention
 
 The convention is such that, if you have a contract in (for example)
@@ -429,6 +431,7 @@ Verifier assumes that there is a `BarBazBase` class under the `com.example.base`
 In other words, the system takes the last two parts of the package, if they exist, and
 forms a class with a `Base` suffix. This rule takes precedence over `baseClassForTests`.
 
+[[by-mapping]]
 === By Mapping
 
 You can manually map a regular expression of the contract's package to the fully qualified

docs/modules/ROOT/pages/legal.adoc

@@ -1,4 +1,5 @@
 [legal]
+[[legal]]
 = Legal
 
 {project-version}
@@ -8,4 +9,4 @@ Copyright © 2012-2020
 Copies of this document may be made for your own use and for distribution to
 others, provided that you do not charge any fee for such copies and further
 provided that each copy contains this Copyright Notice, whether distributed in
-print or electronically.
+print or electronically.

docs/modules/ROOT/pages/maven-project.adoc

@@ -1,3 +1,4 @@
+[[maven-project]]
 = Maven Project
 include::_attributes.adoc[]
 
@@ -383,6 +384,7 @@ plugin which class should get extended by the autogenerated tests. You have two
 * Follow a convention by providing a value for `packageWithBaseClasses`
 * Provide explicit mapping with `baseClassMappings`
 
+[[by-convention]]
 === By Convention
 
 The convention is such that if you have a contract under (for example)
@@ -400,6 +402,7 @@ include::{plugins_path}/spring-cloud-contract-maven-plugin/src/test/projects/bas
 ----
 ====
 
+[[by-mapping]]
 === By Mapping
 
 You can manually map a regular expression of the contract's package to the fully qualified
@@ -629,6 +632,7 @@ To fix this issue, provide the following section in your `pom.xml`:
 ----
 ====
 
+[[maven-plugin-with-spock-tests]]
 == Maven Plugin with Spock Tests
 
 You can select the http://spockframework.org/[Spock Framework] for creating and running the auto-generated contract

docs/modules/ROOT/pages/sagan-boot.adoc

@@ -1,3 +1,4 @@
+[[on-the-producer-side]]
 == On the Producer Side
 
 To start working with Spring Cloud Contract, you can add files with REST or messaging contracts expressed in either Groovy DSL or YAML to the contracts directory, which is set by the contractsDslDir property. By default, it is $rootDir/src/test/resources/contracts.
@@ -55,6 +56,7 @@ INFO: The baseClassForTests element lets you specify your base test class. It mu
 
 Once the implementation and the test base class are in place, the tests pass, and both the application and the stub artifacts are built and installed in the local Maven repository. You can now merge the changes, and you can publish both the application and the stub artifacts in an online repository.
 
+[[on-the-consumer-side]]
 == On the Consumer Side
 
 You can use Spring Cloud Contract Stub Runner in the integration tests to get a running WireMock instance or messaging route that simulates the actual service.

docs/modules/ROOT/pages/using.adoc

@@ -20,6 +20,7 @@ You can check the <<getting-started.adoc#getting-started-first-application, Deve
 
 In this flow, we perform the provider contract testing (the producer has no knowledge of how consumers use their API). The stubs are uploaded to a separate repository (they are not uploaded to Artifactory or Nexus).
 
+[[prerequisites]]
 === Prerequisites
 
 Before testing provider contracts with stubs in git, you must provide a git repository
@@ -189,6 +190,7 @@ with contracts on the producer side flow.
 In this flow, we perform Consumer Driven Contract testing. The contract definitions are
 stored in a separate repository.
 
+[[prerequisites]]
 === Prerequisites
 
 To use consumer-driven contracts with the contracts held in an external repository, you need to set up a git repository that: