Trim IDs with parent

Author: rwinch

framework-docs/modules/ROOT/pages/core/aop/ataspectj/aspectj-support.adoc

@@ -48,7 +48,7 @@ element, as the following example shows:
 
 This assumes that you use schema support as described in
 xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration].
-See xref:core/appendix/xsd-schemas.adoc#core.appendix.xsd-schemas-aop[the AOP schema] for how to
+See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema] for how to
 import the tags in the `aop` namespace.
 
 

framework-docs/modules/ROOT/pages/core/aop/schema.adoc

@@ -10,7 +10,7 @@ of advice parameters.
 
 To use the aop namespace tags described in this section, you need to import the
 `spring-aop` schema, as described in xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]
-. See xref:core/appendix/xsd-schemas.adoc#core.appendix.xsd-schemas-aop[the AOP schema]
+. See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema]
 for how to import the tags in the `aop` namespace.
 
 Within your Spring configurations, all aspect and advisor elements must be placed within

framework-docs/modules/ROOT/pages/core/aop/using-aspectj.adoc

@@ -182,7 +182,7 @@ use Java-based configuration, you can add `@EnableSpringConfigured` to any
 ----
 
 If you prefer XML based configuration, the Spring
-xref:core/appendix/xsd-schemas.adoc#core.appendix.xsd-schemas-context[`context` namespace]
+xref:core/appendix/xsd-schemas.adoc#context[`context` namespace]
 defines a convenient `context:spring-configured` element, which you can use as follows:
 
 [source,xml,indent=0,subs="verbatim"]

framework-docs/modules/ROOT/pages/core/aot.adoc

@@ -1,11 +1,11 @@
-[[core.aot]]
+[[aot]]
 = Ahead of Time Optimizations
 
 This chapter covers Spring's Ahead of Time (AOT) optimizations.
 
 For AOT support specific to integration tests, see xref:testing/testcontext-framework/aot.adoc[Ahead of Time Support for Tests].
 
-[[core.aot.introduction]]
+[[aot.introduction]]
 == Introduction to Ahead of Time Optimizations
 
 Spring's support for AOT optimizations is meant to inspect an `ApplicationContext` at build time and apply decisions and discovery logic that usually happens at runtime.
@@ -30,7 +30,7 @@ A Spring AOT processed application typically generates:
 NOTE: At the moment, AOT is focused on allowing Spring applications to be deployed as native images using GraalVM.
 We intend to support more JVM-based use cases in future generations.
 
-[[core.aot.basics]]
+[[aot.basics]]
 == AOT engine overview
 
 The entry point of the AOT engine for processing an `ApplicationContext` arrangement is `ApplicationContextAotGenerator`. It takes care of the following steps, based on a `GenericApplicationContext` that represents the application to optimize and a {api-spring-framework}/aot/generate/GenerationContext.html[`GenerationContext`]:
@@ -46,21 +46,21 @@ The `RuntimeHints` instance can also be used to generate the relevant GraalVM na
 
 Those steps are covered in greater detail in the sections below.
 
-[[core.aot.refresh]]
+[[aot.refresh]]
 == Refresh for AOT Processing
 
 Refresh for AOT processing is supported on all `GenericApplicationContext` implementations.
 An application context is created with any number of entry points, usually in the form of `@Configuration`-annotated classes.
 
 Let's look at a basic example:
 
-include-code::AotProcessingSample[tag=myapplication]
+include-code::./AotProcessingSample[tag=myapplication]
 
 Starting this application with the regular runtime involves a number of steps including classpath scanning, configuration class parsing, bean instantiation, and lifecycle callback handling.
 Refresh for AOT processing only applies a subset of what happens with a xref:core/beans/introduction.adoc[regular `refresh`].
 AOT processing can be triggered as follows:
 
-include-code::AotProcessingSample[tag=aotcontext]
+include-code::./AotProcessingSample[tag=aotcontext]
 
 In this mode, xref:core/beans/factory-extension.adoc#beans-factory-extension-factory-postprocessors[`BeanFactoryPostProcessor` implementations] are invoked as usual.
 This includes configuration class parsing, import selectors, classpath scanning, etc.
@@ -76,7 +76,7 @@ This makes sure to create any proxy that will be required at runtime.
 
 Once this part completes, the `BeanFactory` contains the bean definitions that are necessary for the application to run. It does not trigger bean instantiation but allows the AOT engine to inspect the beans that will be created at runtime.
 
-[[core.aot.bean-factory-initialization-contributions]]
+[[aot.bean-factory-initialization-contributions]]
 == Bean Factory Initialization AOT Contributions
 
 Components that want to participate in this step can implement the {api-spring-framework}/beans/factory/aot/BeanFactoryInitializationAotProcessor.html[`BeanFactoryInitializationAotProcessor`] interface.
@@ -99,7 +99,7 @@ If such a bean is registered using an `@Bean` factory method, ensure the method
 ====
 
 
-[[core.aot.bean-registration-contributions]]
+[[aot.bean-registration-contributions]]
 === Bean Registration AOT Contributions
 
 A core `BeanFactoryInitializationAotProcessor` implementation is responsible for collecting the necessary contributions for each candidate `BeanDefinition`.
@@ -186,7 +186,7 @@ When a `datasource` instance is required, a `BeanInstanceSupplier` is called.
 This supplier invokes the `dataSource()` method on the `dataSourceConfiguration` bean.
 
 
-[[core.aot.hints]]
+[[aot.hints]]
 == Runtime Hints
 
 Running an application as a native image requires additional information compared to a regular JVM runtime.
@@ -210,22 +210,22 @@ For cases that the core container cannot infer, you can register such hints prog
 A number of convenient annotations are also provided for common use cases.
 
 
-[[core.aot.hints.import-runtime-hints]]
+[[aot.hints.import-runtime-hints]]
 === `@ImportRuntimeHints`
 
 `RuntimeHintsRegistrar` implementations allow you to get a callback to the `RuntimeHints` instance managed by the AOT engine.
 Implementations of this interface can be registered using `@ImportRuntimeHints` on any Spring bean or `@Bean` factory method.
 `RuntimeHintsRegistrar` implementations are detected and invoked at build time.
 
-include-code::SpellCheckService[]
+include-code::./SpellCheckService[]
 
 If at all possible, `@ImportRuntimeHints` should be used as close as possible to the component that requires the hints.
 This way, if the component is not contributed to the `BeanFactory`, the hints won't be contributed either.
 
 It is also possible to register an implementation statically by adding an entry in `META-INF/spring/aot.factories` with a key equal to the fully qualified name of the `RuntimeHintsRegistrar` interface.
 
 
-[[core.aot.hints.reflective]]
+[[aot.hints.reflective]]
 === `@Reflective`
 
 {api-spring-framework}/aot/hint/annotation/Reflective.html[`@Reflective`] provides an idiomatic way to flag the need for reflection on an annotated element.
@@ -239,7 +239,7 @@ Library authors can reuse this annotation for their own purposes.
 If components other than Spring beans need to be processed, a `BeanFactoryInitializationAotProcessor` can detect the relevant types and use `ReflectiveRuntimeHintsRegistrar` to process them.
 
 
-[[core.aot.hints.register-reflection-for-binding]]
+[[aot.hints.register-reflection-for-binding]]
 === `@RegisterReflectionForBinding`
 
 {api-spring-framework}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`] is a specialization of `@Reflective` that registers the need for serializing arbitrary types.
@@ -262,14 +262,14 @@ The following example registers `Account` for serialization.
 	}
 ----
 
-[[core.aot.hints.testing]]
+[[aot.hints.testing]]
 === Testing Runtime Hints
 
 Spring Core also ships `RuntimeHintsPredicates`, a utility for checking that existing hints match a particular use case.
 This can be used in your own tests to validate that a `RuntimeHintsRegistrar` contains the expected results.
 We can write a test for our `SpellCheckService` and ensure that we will be able to load a dictionary at runtime:
 
-include-code::SpellCheckServiceTests[tag=hintspredicates]
+include-code::./SpellCheckServiceTests[tag=hintspredicates]
 
 With `RuntimeHintsPredicates`, we can check for reflection, resource, serialization, or proxy generation hints.
 This approach works well for unit tests but implies that the runtime behavior of a component is well known.
@@ -281,11 +281,11 @@ For more targeted discovery and testing, Spring Framework ships a dedicated modu
 This module contains the RuntimeHints Agent, a Java agent that records all method invocations that are related to runtime hints and helps you to assert that a given `RuntimeHints` instance covers all recorded invocations.
 Let's consider a piece of infrastructure for which we'd like to test the hints we're contributing during the AOT processing phase.
 
-include-code::SampleReflection[]
+include-code::./SampleReflection[]
 
 We can then write a unit test (no native compilation required) that checks our contributed hints:
 
-include-code::SampleReflectionRuntimeHintsTests[]
+include-code::./SampleReflectionRuntimeHintsTests[]
 
 If you forgot to contribute a hint, the test will fail and provide some details about the invocation:
 

framework-docs/modules/ROOT/pages/core/appendix.adoc

@@ -1,4 +1,4 @@
-[[core.appendix]]
+[[appendix]]
 = Appendix
 :page-section-summary-toc: 1
 

framework-docs/modules/ROOT/pages/core/appendix/application-startup-steps.adoc

@@ -1,4 +1,4 @@
-[[core.appendix.application-startup-steps]]
+[[application-startup-steps]]
 = Application Startup Steps
 
 This part of the appendix lists the existing `StartupSteps` that the core container is instrumented with.

framework-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc

@@ -1,7 +1,7 @@
-[[core.appendix.xml-custom]]
+[[xml-custom]]
 = XML Schema Authoring
 
-[[core.appendix.xsd-custom-introduction]]
+[[xsd-custom-introduction]]
 Since version 2.0, Spring has featured a mechanism for adding schema-based extensions to the
 basic Spring XML format for defining and configuring beans. This section covers
 how to write your own custom XML bean definition parsers and
@@ -39,7 +39,7 @@ through the basic steps of making a custom extension.)
 
 
 
-[[core.appendix.xsd-custom-schema]]
+[[xsd-custom-schema]]
 == Authoring the Schema
 
 Creating an XML configuration extension for use with Spring's IoC container starts with
@@ -111,7 +111,7 @@ defined in the enumeration.
 
 
 
-[[core.appendix.xsd-custom-namespacehandler]]
+[[xsd-custom-namespacehandler]]
 == Coding a `NamespaceHandler`
 
 In addition to the schema, we need a `NamespaceHandler` to parse all elements of
@@ -182,7 +182,7 @@ custom element, as we can see in the next step.
 
 
 
-[[core.appendix.xsd-custom-parser]]
+[[xsd-custom-parser]]
 == Using `BeanDefinitionParser`
 
 A `BeanDefinitionParser` is used if the `NamespaceHandler` encounters an XML
@@ -272,7 +272,7 @@ is the extraction and setting of the bean definition's unique identifier.
 
 
 
-[[core.appendix.xsd-custom-registration]]
+[[xsd-custom-registration]]
 == Registering the Handler and the Schema
 
 The coding is finished. All that remains to be done is to make the Spring XML
@@ -284,7 +284,7 @@ XML parsing infrastructure automatically picks up your new extension by consumin
 these special properties files, the formats of which are detailed in the next two sections.
 
 
-[[core.appendix.xsd-custom-registration-spring-handlers]]
+[[xsd-custom-registration-spring-handlers]]
 === Writing `META-INF/spring.handlers`
 
 The properties file called `spring.handlers` contains a mapping of XML Schema URIs to
@@ -303,7 +303,7 @@ namespace extension and needs to exactly match exactly the value of the `targetN
 attribute, as specified in your custom XSD schema.
 
 
-[[core.appendix.xsd-custom-registration-spring-schemas]]
+[[xsd-custom-registration-spring-schemas]]
 === Writing 'META-INF/spring.schemas'
 
 The properties file called `spring.schemas` contains a mapping of XML Schema locations
@@ -327,7 +327,7 @@ the `NamespaceHandler` and `BeanDefinitionParser` classes on the classpath.
 
 
 
-[[core.appendix.xsd-custom-using]]
+[[xsd-custom-using]]
 == Using a Custom Extension in Your Spring XML Configuration
 
 Using a custom extension that you yourself have implemented is no different from using
@@ -361,13 +361,13 @@ in a Spring XML configuration file:
 
 
 
-[[core.appendix.xsd-custom-meat]]
+[[xsd-custom-meat]]
 == More Detailed Examples
 
 This section presents some more detailed examples of custom XML extensions.
 
 
-[[core.appendix.xsd-custom-custom-nested]]
+[[xsd-custom-custom-nested]]
 === Nesting Custom Elements within Custom Elements
 
 The example presented in this section shows how you to write the various artifacts required
@@ -719,7 +719,7 @@ http\://www.foo.example/schema/component/component.xsd=com/foo/component.xsd
 ----
 
 
-[[core.appendix.xsd-custom-custom-just-attributes]]
+[[xsd-custom-custom-just-attributes]]
 === Custom Attributes on "`Normal`" Elements
 
 Writing your own custom parser and the associated artifacts is not hard. However,