Extract recurring asciidoc links to attributes, cleanup old doc files
This commit extract spring-related links and recurring external links into asciidoctor attributes to be used by the Antora toolchain. It notably homogenizes links to: - IETF RFCs - Java Community Process JSRs - the Java API Documentation (on the Java 17 version) - Kotlin documentations (on the Kotlinlang.org version) - the Spring Boot reference guide (on the `html` version) This commit also reworks most link attributes to follow a Project-Category-Misc syntax. For example, `spring-boot-docs` rather than `docs-spring-boot`. Finally, it makes an effort to clean up remainders from the previous documentation toolchain, namely the `docs/asciidoc` folder and `modules/ROOT/pages/attributes.adoc` file. Closes gh-26864 Closes gh-31619
This commit is contained in:
Simon Baslé
@@ -74,6 +74,6 @@ and registering it by using the `resolver` attribute of `@ActiveProfiles`.
|
||||
|
||||
See xref:testing/testcontext-framework/ctx-management/env-profiles.adoc[Context Configuration with Environment Profiles],
|
||||
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration], and the
|
||||
{api-spring-framework}/test/context/ActiveProfiles.html[`@ActiveProfiles`] javadoc for
|
||||
{spring-framework-api}/test/context/ActiveProfiles.html[`@ActiveProfiles`] javadoc for
|
||||
examples and further details.
|
||||
|
||||
|
||||
@@ -40,6 +40,6 @@ Kotlin::
|
||||
By default, `@ContextCustomizerFactories` provides support for inheriting factories from
|
||||
superclasses or enclosing classes. See
|
||||
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] and the
|
||||
{api-spring-framework}/test/context/ContextCustomizerFactories.html[`@ContextCustomizerFactories`
|
||||
{spring-framework-api}/test/context/ContextCustomizerFactories.html[`@ContextCustomizerFactories`
|
||||
javadoc] for an example and further details.
|
||||
|
||||
|
||||
@@ -70,6 +70,6 @@ If you need to merge or override the configuration for a given level of the cont
|
||||
hierarchy within a test class hierarchy, you must explicitly name that level by supplying
|
||||
the same value to the `name` attribute in `@ContextConfiguration` at each corresponding
|
||||
level in the class hierarchy. See xref:testing/testcontext-framework/ctx-management/hierarchies.adoc[Context Hierarchies] and the
|
||||
{api-spring-framework}/test/context/ContextHierarchy.html[`@ContextHierarchy`] javadoc
|
||||
{spring-framework-api}/test/context/ContextHierarchy.html[`@ContextHierarchy`] javadoc
|
||||
for further examples.
|
||||
|
||||
|
||||
@@ -257,6 +257,6 @@ Kotlin::
|
||||
|
||||
|
||||
For further details regarding the `EXHAUSTIVE` and `CURRENT_LEVEL` algorithms, see the
|
||||
{api-spring-framework}/test/annotation/DirtiesContext.HierarchyMode.html[`DirtiesContext.HierarchyMode`]
|
||||
{spring-framework-api}/test/annotation/DirtiesContext.HierarchyMode.html[`DirtiesContext.HierarchyMode`]
|
||||
javadoc.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ _dynamic_ properties to be added to the set of `PropertySources` in the `Environ
|
||||
an `ApplicationContext` loaded for an integration test. Dynamic properties are useful
|
||||
when you do not know the value of the properties upfront – for example, if the properties
|
||||
are managed by an external resource such as for a container managed by the
|
||||
https://www.testcontainers.org/[Testcontainers] project.
|
||||
{testcontainers-site}[Testcontainers] project.
|
||||
|
||||
The following example demonstrates how to register a dynamic property:
|
||||
|
||||
|
||||
@@ -9,6 +9,6 @@ _Spring TestContext Framework_ to record all application events that are publish
|
||||
The recorded events can be accessed via the `ApplicationEvents` API within tests.
|
||||
|
||||
See xref:testing/testcontext-framework/application-events.adoc[Application Events] and the
|
||||
{api-spring-framework}/test/context/event/RecordApplicationEvents.html[`@RecordApplicationEvents`
|
||||
{spring-framework-api}/test/context/event/RecordApplicationEvents.html[`@RecordApplicationEvents`
|
||||
javadoc] for an example and further details.
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ Kotlin::
|
||||
By default, `@TestExecutionListeners` provides support for inheriting listeners from
|
||||
superclasses or enclosing classes. See
|
||||
xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] and the
|
||||
{api-spring-framework}/test/context/TestExecutionListeners.html[`@TestExecutionListeners`
|
||||
{spring-framework-api}/test/context/TestExecutionListeners.html[`@TestExecutionListeners`
|
||||
javadoc] for an example and further details. If you discover that you need to switch
|
||||
back to using the default `TestExecutionListener` implementations, see the note
|
||||
in xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-registering-tels[Registering `TestExecutionListener` Implementations].
|
||||
|
||||
@@ -80,6 +80,6 @@ Kotlin::
|
||||
Note that `@WebAppConfiguration` must be used in conjunction with
|
||||
`@ContextConfiguration`, either within a single test class or within a test class
|
||||
hierarchy. See the
|
||||
{api-spring-framework}/test/context/web/WebAppConfiguration.html[`@WebAppConfiguration`]
|
||||
{spring-framework-api}/test/context/web/WebAppConfiguration.html[`@WebAppConfiguration`]
|
||||
javadoc for further details.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user