Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Extract recurring asciidoc links to attributes, cleanup old doc files

Browse Source 
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é
2023-11-21 15:59:24 +01:00
committed by GitHub
parent 4cc43b4ddc
commit 8567402969
202 changed files with 594 additions and 2837 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
framework-docs/modules/ROOT/pages/testing/testcontext-framework/aot.adoc
View File

@@ -52,13 +52,13 @@ To provide test-specific runtime hints for use within a GraalVM native image, yo
the following options.
* Implement a custom
{api-spring-framework}/test/context/aot/TestRuntimeHintsRegistrar.html[`TestRuntimeHintsRegistrar`]
{spring-framework-api}/test/context/aot/TestRuntimeHintsRegistrar.html[`TestRuntimeHintsRegistrar`]
and register it globally via `META-INF/spring/aot.factories`.
* Implement a custom {api-spring-framework}/aot/hint/RuntimeHintsRegistrar.html[`RuntimeHintsRegistrar`]
* Implement a custom {spring-framework-api}/aot/hint/RuntimeHintsRegistrar.html[`RuntimeHintsRegistrar`]
and register it globally via `META-INF/spring/aot.factories` or locally on a test class
via {api-spring-framework}/context/annotation/ImportRuntimeHints.html[`@ImportRuntimeHints`].
* Annotate a test class with {api-spring-framework}/aot/hint/annotation/Reflective.html[`@Reflective`] or
{api-spring-framework}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`].
via {spring-framework-api}/context/annotation/ImportRuntimeHints.html[`@ImportRuntimeHints`].
* Annotate a test class with {spring-framework-api}/aot/hint/annotation/Reflective.html[`@Reflective`] or
{spring-framework-api}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`].
* See xref:core/aot.adoc#aot.hints[Runtime Hints] for details on Spring's core runtime hints
and annotation support.
@@ -71,12 +71,12 @@ that are not specific to particular test classes, favor implementing
====
If you implement a custom `ContextLoader`, it must implement
{api-spring-framework}/test/context/aot/AotContextLoader.html[`AotContextLoader`] in
{spring-framework-api}/test/context/aot/AotContextLoader.html[`AotContextLoader`] in
order to provide AOT build-time processing and AOT runtime execution support. Note,
however, that all context loader implementations provided by the Spring Framework and
Spring Boot already implement `AotContextLoader`.
If you implement a custom `TestExecutionListener`, it must implement
{api-spring-framework}/test/context/aot/AotTestExecutionListener.html[`AotTestExecutionListener`]
{spring-framework-api}/test/context/aot/AotTestExecutionListener.html[`AotTestExecutionListener`]
in order to participate in AOT processing. See the `SqlScriptsTestExecutionListener` in
the `spring-test` module for an example.

4
framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc
View File

@@ -24,7 +24,7 @@ To use `ApplicationEvents` in your tests, do the following.
to an `@Autowired` field in the test class.
The following test class uses the `SpringExtension` for JUnit Jupiter and
https://assertj.github.io/doc/[AssertJ] to assert the types of application events
{assertj-docs}[AssertJ] to assert the types of application events
published while invoking a method in a Spring-managed component:
// Don't use "quotes" in the "subs" section because of the asterisks in /* ... */
@@ -88,6 +88,6 @@ Kotlin::
======
See the
{api-spring-framework}/test/context/event/ApplicationEvents.html[`ApplicationEvents`
{spring-framework-api}/test/context/event/ApplicationEvents.html[`ApplicationEvents`
javadoc] for further details regarding the `ApplicationEvents` API.

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/context-customizers.adoc
View File

@@ -29,7 +29,7 @@ You can register `ContextCustomizerFactory` implementations explicitly for a tes
subclasses, and its nested classes by using the `@ContextCustomizerFactories` annotation. See
xref:testing/annotations/integration-spring/annotation-contextcustomizerfactories.adoc[annotation support]
and the javadoc for
{api-spring-framework}/test/context/ContextCustomizerFactories.html[`@ContextCustomizerFactories`]
{spring-framework-api}/test/context/ContextCustomizerFactories.html[`@ContextCustomizerFactories`]
for details and examples.

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc
View File

@@ -11,7 +11,7 @@ integration test.
====
The `@DynamicPropertySource` annotation and its supporting infrastructure were
originally designed to allow properties from
https://www.testcontainers.org/[Testcontainers] based tests to be exposed easily to
{testcontainers-site}[Testcontainers] based tests to be exposed easily to
Spring integration tests. However, this feature may also be used with any form of
external resource whose lifecycle is maintained outside the test's `ApplicationContext`.
====

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc
View File

@@ -478,7 +478,7 @@ programmatically instead of declaratively -- for example, based on:
To resolve active bean definition profiles programmatically, you can implement
a custom `ActiveProfilesResolver` and register it by using the `resolver`
attribute of `@ActiveProfiles`. For further information, see the corresponding
{api-spring-framework}/test/context/ActiveProfilesResolver.html[javadoc].
{spring-framework-api}/test/context/ActiveProfilesResolver.html[javadoc].
The following example demonstrates how to implement and register a custom
`OperatingSystemActiveProfilesResolver`:

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc
View File

@@ -235,6 +235,6 @@ NOTE: If you use `@DirtiesContext` in a test whose context is configured as part
context hierarchy, you can use the `hierarchyMode` flag to control how the context cache
is cleared. For further details, see the discussion of `@DirtiesContext` in
xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[Spring Testing Annotations] and the
{api-spring-framework}/test/annotation/DirtiesContext.html[`@DirtiesContext`] javadoc.
{spring-framework-api}/test/annotation/DirtiesContext.html[`@DirtiesContext`] javadoc.
--

6
framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc
View File

@@ -51,8 +51,8 @@ The term "`component class`" can refer to any of the following:
of a single constructor without the use of Spring annotations.
See the javadoc of
{api-spring-framework}/context/annotation/Configuration.html[`@Configuration`] and
{api-spring-framework}/context/annotation/Bean.html[`@Bean`] for further information
{spring-framework-api}/context/annotation/Configuration.html[`@Configuration`] and
{spring-framework-api}/context/annotation/Bean.html[`@Bean`] for further information
regarding the configuration and semantics of component classes, paying special attention
to the discussion of `@Bean` Lite Mode.
====
@@ -62,7 +62,7 @@ TestContext framework tries to detect the presence of default configuration clas
Specifically, `AnnotationConfigContextLoader` and `AnnotationConfigWebContextLoader`
detect all `static` nested classes of the test class that meet the requirements for
configuration class implementations, as specified in the
{api-spring-framework}/context/annotation/Configuration.html[`@Configuration`] javadoc.
{spring-framework-api}/context/annotation/Configuration.html[`@Configuration`] javadoc.
Note that the name of the configuration class is arbitrary. In addition, a test class can
contain more than one `static` nested configuration class if desired. In the following
example, the `OrderServiceTest` class declares a `static` nested configuration class

12
framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc
View File

@@ -29,7 +29,7 @@ integration test methods.
scripts and is mainly intended for internal use within the framework. However, if you
require full control over how SQL scripts are parsed and run, `ScriptUtils` may suit
your needs better than some of the other alternatives described later. See the
{api-spring-framework}/jdbc/datasource/init/ScriptUtils.html[javadoc] for individual
{spring-framework-api}/jdbc/datasource/init/ScriptUtils.html[javadoc] for individual
methods in `ScriptUtils` for further details.
`ResourceDatabasePopulator` provides an object-based API for programmatically populating,
@@ -38,7 +38,7 @@ resources. `ResourceDatabasePopulator` provides options for configuring the char
encoding, statement separator, comment delimiters, and error handling flags used when
parsing and running the scripts. Each of the configuration options has a reasonable
default value. See the
{api-spring-framework}/jdbc/datasource/init/ResourceDatabasePopulator.html[javadoc] for
{spring-framework-api}/jdbc/datasource/init/ResourceDatabasePopulator.html[javadoc] for
details on default values. To run the scripts configured in a
`ResourceDatabasePopulator`, you can invoke either the `populate(Connection)` method to
run the populator against a `java.sql.Connection` or the `execute(DataSource)` method
@@ -392,8 +392,8 @@ local `@SqlConfig` attributes do not supply an explicit value other than `""`, `
The configuration options provided by `@Sql` and `@SqlConfig` are equivalent to those
supported by `ScriptUtils` and `ResourceDatabasePopulator` but are a superset of those
provided by the `<jdbc:initialize-database/>` XML namespace element. See the javadoc of
individual attributes in {api-spring-framework}/test/context/jdbc/Sql.html[`@Sql`] and
{api-spring-framework}/test/context/jdbc/SqlConfig.html[`@SqlConfig`] for details.
individual attributes in {spring-framework-api}/test/context/jdbc/Sql.html[`@Sql`] and
{spring-framework-api}/test/context/jdbc/SqlConfig.html[`@SqlConfig`] for details.
[[testcontext-executing-sql-declaratively-tx]]
==== Transaction management for `@Sql`
@@ -415,8 +415,8 @@ behavior by setting the `transactionMode` attribute of `@SqlConfig` (for example
scripts should be run in an isolated transaction). Although a thorough discussion of all
supported options for transaction management with `@Sql` is beyond the scope of this
reference manual, the javadoc for
{api-spring-framework}/test/context/jdbc/SqlConfig.html[`@SqlConfig`] and
{api-spring-framework}/test/context/jdbc/SqlScriptsTestExecutionListener.html[`SqlScriptsTestExecutionListener`]
{spring-framework-api}/test/context/jdbc/SqlConfig.html[`@SqlConfig`] and
{spring-framework-api}/test/context/jdbc/SqlScriptsTestExecutionListener.html[`SqlScriptsTestExecutionListener`]
provide detailed information, and the following example shows a typical testing scenario
that uses JUnit Jupiter and transactional tests with `@Sql`:

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/key-abstractions.adoc
View File

@@ -10,7 +10,7 @@ in turn, manages a `TestContext` that holds the context of the current test. The
and delegates to `TestExecutionListener` implementations, which instrument the actual
test execution by providing dependency injection, managing transactions, and so on. A
`SmartContextLoader` is responsible for loading an `ApplicationContext` for a given test
class. See the {api-spring-framework}/test/context/package-summary.html[javadoc] and the
class. See the {spring-framework-api}/test/context/package-summary.html[javadoc] and the
Spring test suite for further information and examples of various implementations.
[[testcontext]]

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc
View File

@@ -40,7 +40,7 @@ for details.
WARNING: Parallel test execution in the Spring TestContext Framework is only possible if
the underlying `TestContext` implementation provides a copy constructor, as explained in
the javadoc for {api-spring-framework}/test/context/TestContext.html[`TestContext`]. The
the javadoc for {spring-framework-api}/test/context/TestContext.html[`TestContext`]. The
`DefaultTestContext` used in Spring provides such a constructor. However, if you use a
third-party library that provides a custom `TestContext` implementation, you need to
verify that it is suitable for parallel test execution.

2
framework-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc
View File

@@ -29,7 +29,7 @@ by default, exactly in the following order:
You can register `TestExecutionListener` implementations explicitly for a test class, its
subclasses, and its nested classes by using the `@TestExecutionListeners` annotation. See
xref:testing/annotations.adoc[annotation support] and the javadoc for
{api-spring-framework}/test/context/TestExecutionListeners.html[`@TestExecutionListeners`]
{spring-framework-api}/test/context/TestExecutionListeners.html[`@TestExecutionListeners`]
for details and examples.
.Switching to default `TestExecutionListener` implementations

6
framework-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc
View File

@@ -216,7 +216,7 @@ Support for `TestTransaction` is automatically available whenever the
`TransactionalTestExecutionListener` is enabled.
The following example demonstrates some of the features of `TestTransaction`. See the
javadoc for {api-spring-framework}/test/context/transaction/TestTransaction.html[`TestTransaction`]
javadoc for {spring-framework-api}/test/context/transaction/TestTransaction.html[`TestTransaction`]
for further details.
[tabs]
@@ -355,7 +355,7 @@ of `PlatformTransactionManager` within the test's `ApplicationContext`, you can
qualifier by using `@Transactional("myTxMgr")` or `@Transactional(transactionManager =
"myTxMgr")`, or `TransactionManagementConfigurer` can be implemented by an
`@Configuration` class. Consult the
{api-spring-framework}/test/context/transaction/TestContextTransactionUtils.html#retrieveTransactionManager-org.springframework.test.context.TestContext-java.lang.String-[javadoc
{spring-framework-api}/test/context/transaction/TestContextTransactionUtils.html#retrieveTransactionManager-org.springframework.test.context.TestContext-java.lang.String-[javadoc
for `TestContextTransactionUtils.retrieveTransactionManager()`] for details on the
algorithm used to look up a transaction manager in the test's `ApplicationContext`.
@@ -668,7 +668,7 @@ Kotlin::
======
See
https://github.com/spring-projects/spring-framework/blob/main/spring-test/src/test/java/org/springframework/test/context/junit/jupiter/orm/JpaEntityListenerTests.java[JpaEntityListenerTests]
{spring-framework-code}/spring-test/src/test/java/org/springframework/test/context/junit/jupiter/orm/JpaEntityListenerTests.java[JpaEntityListenerTests]
in the Spring Framework test suite for working examples using all JPA lifecycle callbacks.
=====