Polishing.

Author: gregturn

src/main/antora/modules/ROOT/pages/repositories-null-handling.adoc

@@ -16,7 +16,7 @@ See "`xref:repository-query-return-types-reference.adoc[Repository query return
 [[repositories.nullability.annotations]]
 == Nullability Annotations
 
-You can express nullability constraints for repository methods by using {spring-framework-docs}/core.html#null-safety[Spring Framework's nullability annotations].
+You can express nullability constraints for repository methods by using {spring-framework-docs}/core/null-safety.html[Spring Framework's nullability annotations].
 They provide a tooling-friendly approach and opt-in `null` checks during runtime, as follows:
 
 * {spring-framework-javadoc}/org/springframework/lang/NonNullApi.html[`@NonNullApi`]: Used on the package level to declare that the default behavior for parameters and return values is, respectively, neither to accept nor to produce `null` values.

src/main/antora/modules/ROOT/pages/repositories/core-extensions.adoc

@@ -439,7 +439,7 @@ The type to which the JSON object is unmarshalled is determined by inspecting th
 The infrastructure eventually selects the appropriate repository to handle the object that was deserialized.
 
 To instead use XML to define the data the repositories should be populated with, you can use the `unmarshaller-populator` element.
-You configure it to use one of the XML marshaller options available in Spring OXM. See the {spring-framework-docs}/data-access.html#oxm[Spring reference documentation] for details.
+You configure it to use one of the XML marshaller options available in Spring OXM. See the {spring-framework-docs}/data-access/oxm.html[Spring reference documentation] for details.
 The following example shows how to unmarshall a repository populator with JAXB:
 
 .Declaring an unmarshalling repository populator (using JAXB)

src/main/antora/modules/ROOT/pages/repositories/create-instances.adoc

@@ -65,7 +65,7 @@ By default, the infrastructure picks up every interface that extends the persist
 However, you might want more fine-grained control over which interfaces have bean instances created for them.
 To do so, use filter elements inside the repository declaration.
 The semantics are exactly equivalent to the elements in Spring's component filters.
-For details, see the {spring-framework-docs}/core.html#beans-scanning-filters[Spring reference documentation] for these elements.
+For details, see the {spring-framework-docs}/core/beans/classpath-scanning.html[Spring reference documentation] for these elements.
 
 For example, to exclude certain interfaces from instantiation as repository beans, you could use the following configuration:
 

src/main/antora/modules/ROOT/pages/repositories/query-methods-details.adoc

@@ -247,7 +247,7 @@ NOTE: Not all Spring Data modules currently support `Stream<T>` as a return type
 [[repositories.query-async]]
 == Asynchronous Query Results
 
-You can run repository queries asynchronously by using {spring-framework-docs}/integration.html#scheduling[Spring's asynchronous method running capability].
+You can run repository queries asynchronously by using {spring-framework-docs}/integration/scheduling.html[Spring's asynchronous method running capability].
 This means the method returns immediately upon invocation while the actual query occurs in a task that has been submitted to a Spring `TaskExecutor`.
 Asynchronous queries differ from reactive queries and should not be mixed.
 See the store-specific documentation for more details on reactive support.