Fix cross references

Author: rwinch

modules/ROOT/pages/auditing.adoc

@@ -9,7 +9,7 @@ Please refer to the store-specific section for configuration samples.
 
 [NOTE]
 ====
-Applications that only track creation and modification dates are not required do make their entities implement <<auditing.auditor-aware, `AuditorAware`>>.
+Applications that only track creation and modification dates are not required do make their entities implement xref:auditing.adoc#auditing.auditor-aware[`AuditorAware`].
 ====
 
 [[auditing.annotations]]

modules/ROOT/pages/dependencies.adoc

@@ -49,7 +49,7 @@ You can find a working example of using the BOMs in our https://github.com/sprin
 == Dependency Management with Spring Boot
 
 Spring Boot selects a recent version of the Spring Data modules for you. If you still want to upgrade to a newer version,
-set the `spring-data-bom.version` property to the <<dependencies.train-version,train version and iteration>>
+set the `spring-data-bom.version` property to the xref:dependencies.adoc#dependencies.train-version[train version and iteration]
 you would like to use.
 
 See Spring Boot's https://docs.spring.io/spring-boot/docs/current/reference/html/dependency-versions.html#appendix.dependency-versions.properties[documentation]

modules/ROOT/pages/kotlin.adoc

@@ -25,7 +25,7 @@ Although Java does not let you express null safety in its type system, Spring Da
 By default, types from Java APIs used in Kotlin are recognized as https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types[platform types], for which null checks are relaxed.
 https://kotlinlang.org/docs/reference/java-interop.html#jsr-305-support[Kotlin support for JSR-305 annotations] and Spring nullability annotations provide null safety for the whole Spring Data API to Kotlin developers, with the advantage of dealing with `null` related issues at compile time.
 
-See <<repositories.nullability>> how null safety applies to Spring Data Repositories.
+See xref:repositories-null-handling.adoc[Null Handling of Repository Methods] how null safety applies to Spring Data Repositories.
 
 [TIP]
 ====
@@ -40,4 +40,4 @@ NOTE: Generic type arguments, varargs, and array elements nullability are not su
 [[kotlin.mapping]]
 == Object Mapping
 
-See <<mapping.kotlin>> for details on how Kotlin objects are materialized.
+See xref:object-mapping.adoc#mapping.kotlin[Kotlin support] for details on how Kotlin objects are materialized.

modules/ROOT/pages/object-mapping.adoc

@@ -78,13 +78,13 @@ For that we use the following algorithm:
 1. If the property is immutable but exposes a `with…` method (see below), we use the `with…` method to create a new entity instance with the new property value.
 2. If property access (i.e. access through getters and setters) is defined, we're invoking the setter method.
 3. If the property is mutable we set the field directly.
-4. If the property is immutable we're using the constructor to be used by persistence operations (see <<mapping.object-creation>>) to create a copy of the instance.
+4. If the property is immutable we're using the constructor to be used by persistence operations (see xref:object-mapping.adoc#mapping.object-creation[Object creation]) to create a copy of the instance.
 5. By default, we set the field value directly.
 
 [[mapping.property-population.details]]
 .Property population internals
 ****
-Similarly to our <<mapping.object-creation.details,optimizations in object construction>> we also use Spring Data runtime generated accessor classes to interact with the entity instance.
+Similarly to our xref:object-mapping.adoc#mapping.object-creation.details[optimizations in object construction] we also use Spring Data runtime generated accessor classes to interact with the entity instance.
 
 [source,java]
 ----
@@ -305,7 +305,7 @@ Spring Data automatically tries to detect a persistent entity's constructor to b
 The resolution algorithm works as follows:
 
 1. If there is a constructor that is annotated with `@PersistenceCreator`, it is used.
-2. If the type is a <<mapping.kotlin,Kotlin data cass>> the primary constructor is used.
+2. If the type is a xref:object-mapping.adoc#mapping.kotlin[Kotlin data cass] the primary constructor is used.
 3. If there is a single static factory method annotated with `@PersistenceCreator` then it is used.
 4. If there is a single constructor, it is used.
 5. If there are multiple constructors and exactly one is annotated with `@PersistenceCreator`, it is used.

modules/ROOT/pages/query-by-example.adoc

@@ -59,9 +59,9 @@ You can use it to create an `Example`.
 By default, fields having `null` values are ignored, and strings are matched by using the store specific defaults.
 
 NOTE: Inclusion of properties into a Query by Example criteria is based on nullability.
-Properties using primitive types (`int`, `double`, …) are always included unless  the <<query-by-example.matchers, `ExampleMatcher` ignores the property path>>.
+Properties using primitive types (`int`, `double`, …) are always included unless  the xref:query-by-example.adoc#query-by-example.matchers[`ExampleMatcher` ignores the property path].
 
-Examples can be built by either using the `of` factory method or by using <<query-by-example.matchers,`ExampleMatcher`>>. `Example` is immutable.
+Examples can be built by either using the `of` factory method or by using xref:query-by-example.adoc#query-by-example.matchers[`ExampleMatcher`]. `Example` is immutable.
 The following listing shows a simple Example:
 
 .Simple Example

modules/ROOT/pages/repositories-null-handling.adoc

@@ -11,7 +11,7 @@ Besides that, Spring Data supports returning the following wrapper types on quer
 Alternatively, query methods can choose not to use a wrapper type at all.
 The absence of a query result is then indicated by returning `null`.
 Repository methods returning collections, collection alternatives, wrappers, and streams are guaranteed never to return `null` but rather the corresponding empty representation.
-See "`<<repository-query-return-types>>`" for details.
+See "`xref:repository-query-return-types-reference.adoc[Repository query return types]`" for details.
 
 [[repositories.nullability.annotations]]
 == Nullability Annotations

modules/ROOT/pages/repositories-scrolling.adoc

@@ -3,7 +3,7 @@
 
 Scrolling is a more fine-grained approach to iterate through larger results set chunks.
 Scrolling consists of a stable sort, a scroll type (Offset- or Keyset-based scrolling) and result limiting.
-You can define simple sorting expressions by using property names and define static result limiting using the <<repositories.limit-query-result,`Top` or `First` keyword>> through query derivation.
+You can define simple sorting expressions by using property names and define static result limiting using the xref:repositories-paging-sorting.adoc#repositories.limit-query-result[`Top` or `First` keyword] through query derivation.
 You can concatenate expressions to collect multiple criteria into one expression.
 
 Scroll queries return a `Window<T>` that allows obtaining the scroll position to resume to obtain the next `Window<T>` until your application has consumed the entire query result.

modules/ROOT/pages/repositories.adoc

@@ -18,7 +18,7 @@ This chapter explains the core concepts and interfaces of Spring Data repositori
 The information in this chapter is pulled from the Spring Data Commons module.
 It uses the configuration and code samples for the Jakarta Persistence API (JPA) module.
 ifeval::[{include-xml-namespaces} != false]
-If you want to use XML configuration you should adapt the XML namespace declaration and the types to be extended to the equivalents of the particular module that you use. "`<<repositories.namespace-reference>>`" covers XML configuration, which is supported across all Spring Data modules that support the repository API.
+If you want to use XML configuration you should adapt the XML namespace declaration and the types to be extended to the equivalents of the particular module that you use. "`xref:repository-namespace-reference.adoc#repositories.namespace-reference[null]`" covers XML configuration, which is supported across all Spring Data modules that support the repository API.
 endif::[]
 "`<<repository-query-keywords>>`" covers the query method keywords supported by the repository abstraction in general.
 For detailed information on the specific features of your module, see the chapter on that module of this document.

modules/ROOT/pages/repositories/core-extensions.adoc

@@ -93,11 +93,11 @@ It also detects Spring HATEOAS on the classpath and registers integration compon
 [[core.web.basic]]
 === Basic Web Support
 
-The configuration shown in the <<core.web,previous section>> registers a few basic components:
+The configuration shown in the xref:repositories/core-extensions.adoc#core.web[previous section] registers a few basic components:
 
-- A <<core.web.basic.domain-class-converter>> to let Spring MVC resolve instances of repository-managed domain classes from request parameters or path variables.
-- <<core.web.basic.paging-and-sorting,`HandlerMethodArgumentResolver`>> implementations to let Spring MVC resolve `Pageable` and `Sort` instances from request parameters.
-- <<core.web.basic.jackson-mappers, Jackson Modules>> to de-/serialize types like `Point` and `Distance`, or store specific ones, depending on the Spring Data Module used.
+- A xref:repositories/core-extensions.adoc#core.web.basic.domain-class-converter[Using the `DomainClassConverter` Class] to let Spring MVC resolve instances of repository-managed domain classes from request parameters or path variables.
+- xref:repositories/core-extensions.adoc#core.web.basic.paging-and-sorting[`HandlerMethodArgumentResolver`] implementations to let Spring MVC resolve `Pageable` and `Sort` instances from request parameters.
+- xref:repositories/core-extensions.adoc#core.web.basic.jackson-mappers[Jackson Modules] to de-/serialize types like `Point` and `Distance`, or store specific ones, depending on the Spring Data Module used.
 
 [[core.web.basic.domain-class-converter]]
 ==== Using the `DomainClassConverter` Class
@@ -130,7 +130,7 @@ NOTE: Currently, the repository has to implement `CrudRepository` to be eligible
 [[core.web.basic.paging-and-sorting]]
 ==== HandlerMethodArgumentResolvers for Pageable and Sort
 
-The configuration snippet shown in the <<core.web.basic.domain-class-converter,previous section>> also registers a `PageableHandlerMethodArgumentResolver` as well as an instance of `SortHandlerMethodArgumentResolver`.
+The configuration snippet shown in the xref:repositories/core-extensions.adoc#core.web.basic.domain-class-converter[previous section] also registers a `PageableHandlerMethodArgumentResolver` as well as an instance of `SortHandlerMethodArgumentResolver`.
 The registration enables `Pageable` and `Sort` as valid controller method arguments, as the following example shows:
 
 .Using Pageable as a controller method argument
@@ -272,7 +272,7 @@ By default, the assembler points to the controller method it was invoked in, but
 === Spring Data Jackson Modules
 
 The core module, and some of the store specific ones, ship with a set of Jackson Modules for types, like `org.springframework.data.geo.Distance` and `org.springframework.data.geo.Point`, used by the Spring Data domain. +
-Those Modules are imported once <<core.web, web support>> is enabled and `com.fasterxml.jackson.databind.ObjectMapper` is available.
+Those Modules are imported once xref:repositories/core-extensions.adoc#core.web[web support] is enabled and `com.fasterxml.jackson.databind.ObjectMapper` is available.
 
 During initialization `SpringDataJacksonModules`, like the `SpringDataJacksonConfiguration`, get picked up by the infrastructure, so that the declared ``com.fasterxml.jackson.databind.Module``s are made available to the Jackson `ObjectMapper`.
 
@@ -294,7 +294,7 @@ Please refer to the store specific section for more details.
 [[core.web.binding]]
 === Web Databinding Support
 
-You can use Spring Data projections (described in <<projections>>) to bind incoming request payloads by using either https://goessner.net/articles/JsonPath/[JSONPath] expressions (requires https://github.com/json-path/JsonPath[Jayway JsonPath]) or https://www.w3.org/TR/xpath-31/[XPath] expressions (requires https://xmlbeam.org/[XmlBeam]), as the following example shows:
+You can use Spring Data projections (described in xref:repository-projections.adoc[Projections]) to bind incoming request payloads by using either https://goessner.net/articles/JsonPath/[JSONPath] expressions (requires https://github.com/json-path/JsonPath[Jayway JsonPath]) or https://www.w3.org/TR/xpath-31/[XPath] expressions (requires https://xmlbeam.org/[XmlBeam]), as the following example shows:
 
 .HTTP payload binding using JSONPath or XPath expressions
 ====
@@ -320,7 +320,7 @@ The `lastname` XML lookup is performed on the top-level of the incoming document
 The JSON variant of that tries a top-level `lastname` first but also tries `lastname` nested in a `user` sub-document if the former does not return a value.
 That way, changes in the structure of the source document can be mitigated easily without having clients calling the exposed methods (usually a drawback of class-based payload binding).
 
-Nested projections are supported as described in <<projections>>.
+Nested projections are supported as described in xref:repository-projections.adoc[Projections].
 If the method returns a complex, non-interface type, a Jackson `ObjectMapper` is used to map the final value.
 
 For Spring MVC, the necessary converters are registered automatically as soon as `@EnableSpringDataWebSupport` is active and the required dependencies are available on the classpath.

modules/ROOT/pages/repositories/custom-implementations.adoc

@@ -54,7 +54,7 @@ interface UserRepository extends CrudRepository<User, Long>, CustomizedUserRepos
 Extending the fragment interface with your repository interface combines the CRUD and custom functionality and makes it available to clients.
 
 Spring Data repositories are implemented by using fragments that form a repository composition.
-Fragments are the base repository, functional aspects (such as <<core.extensions.querydsl,QueryDsl>>), and custom interfaces along with their implementations.
+Fragments are the base repository, functional aspects (such as xref:repositories/core-extensions.adoc#core.extensions.querydsl[QueryDsl]), and custom interfaces along with their implementations.
 Each time you add an interface to your repository interface, you enhance the composition by adding a fragment.
 The base repository and repository aspect implementations are provided by each Spring Data module.
 
@@ -216,7 +216,7 @@ If you annotate the `UserRepository` interface with `@Component("specialCustom")
 ==== Manual Wiring
 
 If your custom implementation uses annotation-based configuration and autowiring only, the preceding approach shown works well, because it is treated as any other Spring bean.
-If your implementation fragment bean needs special wiring, you can declare the bean and name it according to the conventions described in the <<repositories.single-repository-behaviour.ambiguity,preceding section>>.
+If your implementation fragment bean needs special wiring, you can declare the bean and name it according to the conventions described in the xref:repositories/custom-implementations.adoc#repositories.single-repository-behaviour.ambiguity[preceding section].
 The infrastructure then refers to the manually defined bean definition by name instead of creating one itself.
 The following example shows how to manually wire a custom implementation:
 
@@ -250,7 +250,7 @@ endif::[]
 [[repositories.customize-base-repository]]
 == Customize the Base Repository
 
-The approach described in the <<repositories.manual-wiring,preceding section>> requires customization of each repository interfaces when you want to customize the base repository behavior so that all repositories are affected.
+The approach described in the xref:repositories/custom-implementations.adoc#repositories.manual-wiring[preceding section] requires customization of each repository interfaces when you want to customize the base repository behavior so that all repositories are affected.
 To instead change behavior for all repositories, you can create an implementation that extends the persistence technology-specific repository base class.
 This class then acts as a custom base class for the repository proxies, as shown in the following example:
 

modules/ROOT/pages/repositories/definition.adoc

@@ -68,8 +68,8 @@ In such cases, a repository definition must distinguish between persistence tech
 When it detects multiple repository factories on the class path, Spring Data enters strict repository configuration mode.
 Strict configuration uses details on the repository or the domain class to decide about Spring Data module binding for a repository definition:
 
-. If the repository definition <<repositories.multiple-modules.types,extends the module-specific repository>>, it is a valid candidate for the particular Spring Data module.
-. If the domain class is <<repositories.multiple-modules.annotations,annotated with the module-specific type annotation>>, it is a valid candidate for the particular Spring Data module.
+. If the repository definition xref:repositories/definition.adoc#repositories.multiple-modules.types[extends the module-specific repository], it is a valid candidate for the particular Spring Data module.
+. If the domain class is xref:repositories/definition.adoc#repositories.multiple-modules.annotations[annotated with the module-specific type annotation], it is a valid candidate for the particular Spring Data module.
 Spring Data modules accept either third-party annotations (such as JPA's `@Entity`) or provide their own annotations (such as `@Document` for Spring Data MongoDB and Spring Data Elasticsearch).
 
 The following example shows a repository that uses module-specific interfaces (JPA in this case):
@@ -151,14 +151,14 @@ One is intended for JPA and the other for MongoDB usage.
 Spring Data is no longer able to tell the repositories apart, which leads to undefined behavior.
 ====
 
-<<repositories.multiple-modules.types,Repository type details>> and <<repositories.multiple-modules.annotations,distinguishing domain class annotations>> are used for strict repository configuration to identify repository candidates for a particular Spring Data module.
+xref:repositories/definition.adoc#repositories.multiple-modules.types[Repository type details] and xref:repositories/definition.adoc#repositories.multiple-modules.annotations[distinguishing domain class annotations] are used for strict repository configuration to identify repository candidates for a particular Spring Data module.
 Using multiple persistence technology-specific annotations on the same domain type is possible and enables reuse of domain types across multiple persistence technologies.
 However, Spring Data can then no longer determine a unique module with which to bind the repository.
 
 The last way to distinguish repositories is by scoping repository base packages.
 Base packages define the starting points for scanning for repository interface definitions, which implies having repository definitions located in the appropriate packages.
 By default, annotation-driven configuration uses the package of the configuration class.
-The <<repositories.create-instances.xml,base package in XML-based configuration>> is mandatory.
+The xref:repositories/create-instances.adoc#repositories.create-instances.xml[base package in XML-based configuration] is mandatory.
 
 The following example shows annotation-driven configuration of base packages: