Split appendices into multiple pages and include a ToC in each
Closes gh-16289
This commit is contained in:
parent
81ddebbc27
commit
d5adbbb626
|
|
@ -1,8 +1,7 @@
|
|||
:numbered!:
|
||||
[appendix]
|
||||
[[common-application-properties]]
|
||||
== Common application properties
|
||||
|
||||
= Common Application properties
|
||||
include::{asciidoc-sources-root}/attributes.adoc[]
|
||||
|
||||
Various properties can be specified inside your `application.properties` file, inside your `application.yml` file, or as command line switches.
|
||||
|
|
@ -14,66 +13,66 @@ NOTE: Property contributions can come from additional jar files on your classpat
|
|||
Also, you can define your own properties.
|
||||
|
||||
|
||||
=== Core properties
|
||||
== Core properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/core.adoc[]
|
||||
|
||||
=== Cache properties
|
||||
== Cache properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/cache.adoc[]
|
||||
|
||||
=== Mail properties
|
||||
== Mail properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/mail.adoc[]
|
||||
|
||||
=== JSON properties
|
||||
== JSON properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/json.adoc[]
|
||||
|
||||
=== Data properties
|
||||
== Data properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/data.adoc[]
|
||||
|
||||
=== Transaction properties
|
||||
== Transaction properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/transaction.adoc[]
|
||||
|
||||
=== Data migration properties
|
||||
== Data migration properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/data-migration.adoc[]
|
||||
|
||||
=== Integration properties
|
||||
== Integration properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/integration.adoc[]
|
||||
|
||||
=== Web properties
|
||||
== Web properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/web.adoc[]
|
||||
|
||||
=== Templating properties
|
||||
== Templating properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/templating.adoc[]
|
||||
|
||||
=== Server properties
|
||||
== Server properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/server.adoc[]
|
||||
|
||||
=== Security properties
|
||||
== Security properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/security.adoc[]
|
||||
|
||||
=== RSocket properties
|
||||
== RSocket properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/rsocket.adoc[]
|
||||
|
||||
=== Actuator properties
|
||||
== Actuator properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/actuator.adoc[]
|
||||
|
||||
=== Devtools properties
|
||||
== Devtools properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/devtools.adoc[]
|
||||
|
||||
=== Testing properties
|
||||
== Testing properties
|
||||
|
||||
include::{generated-resources-root}/config-docs/testing.adoc[]
|
||||
|
|
@ -1,17 +1,16 @@
|
|||
[appendix]
|
||||
[[auto-configuration-classes]]
|
||||
== Auto-configuration classes
|
||||
|
||||
= Auto-configuration Classes
|
||||
include::{asciidoc-sources-root}/attributes.adoc[]
|
||||
|
||||
Here is a list of all auto-configuration classes provided by Spring Boot, with links to documentation and source code.
|
||||
This appendix contains details of all of the auto-configuration classes provided by Spring Boot, with links to documentation and source code.
|
||||
Remember to also look at the conditions report in your application for more details of which features are switched on.
|
||||
(To do so, start the app with `--debug` or `-Ddebug` or, in an Actuator application, use the `conditions` endpoint).
|
||||
|
||||
|
||||
|
||||
[[auto-configuration-classes-from-autoconfigure-module]]
|
||||
=== From the "`spring-boot-autoconfigure`" module
|
||||
== `spring-boot-autoconfigure`
|
||||
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
|
||||
|
||||
include::{generated-resources-root}/auto-configuration-classes-spring-boot-autoconfigure.adoc[]
|
||||
|
|
@ -19,7 +18,7 @@ include::{generated-resources-root}/auto-configuration-classes-spring-boot-autoc
|
|||
|
||||
|
||||
[[auto-configuration-classes-from-actuator]]
|
||||
=== From the "`spring-boot-actuator-autoconfigure`" module
|
||||
== `spring-boot-actuator-autoconfigure`
|
||||
The following auto-configuration classes are from the `spring-boot-actuator-autoconfigure` module:
|
||||
|
||||
include::{generated-resources-root}/auto-configuration-classes-spring-boot-actuator-autoconfigure.adoc[]
|
||||
|
|
@ -1,7 +1,6 @@
|
|||
[appendix]
|
||||
[[configuration-metadata]]
|
||||
== Configuration Metadata
|
||||
|
||||
= Configuration Metadata
|
||||
include::{asciidoc-sources-root}/attributes.adoc[]
|
||||
|
||||
Spring Boot jars include metadata files that provide details of all supported configuration properties.
|
||||
|
|
@ -13,7 +12,7 @@ However, it is possible to <<configuration-metadata-additional-metadata,write pa
|
|||
|
||||
|
||||
[[configuration-metadata-format]]
|
||||
=== Metadata Format
|
||||
== Metadata Format
|
||||
Configuration metadata files are located inside jars under `META-INF/spring-configuration-metadata.json`.
|
||||
They use a simple JSON format with items categorized under either "`groups`" or "`properties`" and additional values hints categorized under "hints", as shown in the following example:
|
||||
|
||||
|
|
@ -100,7 +99,7 @@ For example, when a developer is configuring the `spring.jpa.hibernate.ddl-auto`
|
|||
|
||||
|
||||
[[configuration-metadata-group-attributes]]
|
||||
==== Group Attributes
|
||||
=== Group Attributes
|
||||
The JSON object contained in the `groups` array can contain the attributes shown in the following table:
|
||||
|
||||
[cols="1,1,4"]
|
||||
|
|
@ -141,7 +140,7 @@ The JSON object contained in the `groups` array can contain the attributes shown
|
|||
|
||||
|
||||
[[configuration-metadata-property-attributes]]
|
||||
==== Property Attributes
|
||||
=== Property Attributes
|
||||
The JSON object contained in the `properties` array can contain the attributes described in the following table:
|
||||
|
||||
[cols="1,1,4"]
|
||||
|
|
@ -256,7 +255,7 @@ Doing so is particularly useful when a `replacement` is provided.
|
|||
|
||||
|
||||
[[configuration-metadata-hints-attributes]]
|
||||
==== Hint Attributes
|
||||
=== Hint Attributes
|
||||
The JSON object contained in the `hints` array can contain the attributes shown in the following table:
|
||||
|
||||
[cols="1,1,4"]
|
||||
|
|
@ -319,7 +318,7 @@ The JSON object contained in the `providers` attribute of each `hint` element ca
|
|||
|
||||
|
||||
[[configuration-metadata-repeated-items]]
|
||||
==== Repeated Metadata Items
|
||||
=== Repeated Metadata Items
|
||||
Objects with the same "`property`" and "`group`" name can appear multiple times within a metadata file.
|
||||
For example, you could bind two separate classes to the same prefix, with each having potentially overlapping property names.
|
||||
While the same names appearing in the metadata multiple times should not be common, consumers of metadata should take care to ensure that they support it.
|
||||
|
|
@ -327,14 +326,14 @@ While the same names appearing in the metadata multiple times should not be comm
|
|||
|
||||
|
||||
[[configuration-metadata-providing-manual-hints]]
|
||||
=== Providing Manual Hints
|
||||
== Providing Manual Hints
|
||||
To improve the user experience and further assist the user in configuring a given property, you can provide additional metadata that:
|
||||
|
||||
* Describes the list of potential values for a property.
|
||||
* Associates a provider, to attach a well defined semantic to a property, so that a tool can discover the list of potential values based on the project's context.
|
||||
|
||||
|
||||
==== Value Hint
|
||||
=== Value Hint
|
||||
The `name` attribute of each hint refers to the `name` of a property.
|
||||
In the <<configuration-metadata-format,initial example shown earlier>>, we provide five values for the `spring.jpa.hibernate.ddl-auto` property: `none`, `validate`, `update`, `create`, and `create-drop`.
|
||||
Each value may have a description as well.
|
||||
|
|
@ -379,7 +378,7 @@ If your IDE supports it, this is by far the most effective approach to auto-comp
|
|||
|
||||
|
||||
|
||||
==== Value Providers
|
||||
=== Value Providers
|
||||
Providers are a powerful way to attach semantics to a property.
|
||||
In this section, we define the official providers that you can use for your own hints.
|
||||
However, your favorite IDE may implement some of these or none of them.
|
||||
|
|
@ -422,7 +421,7 @@ If no provider for a given property is supported, no special content assistance
|
|||
|
||||
|
||||
|
||||
===== Any
|
||||
==== Any
|
||||
The special **any** provider value permits any additional values to be provided.
|
||||
Regular value validation based on the property type should be applied if this is supported.
|
||||
|
||||
|
|
@ -454,7 +453,7 @@ The following example offers `on` and `off` as auto-completion values for `syste
|
|||
|
||||
Note that, in the preceding example, any other value is also allowed.
|
||||
|
||||
===== Class Reference
|
||||
==== Class Reference
|
||||
The **class-reference** provider auto-completes classes available in the project.
|
||||
This provider supports the following parameters:
|
||||
|
||||
|
|
@ -497,7 +496,7 @@ The following metadata snippet corresponds to the standard `server.servlet.jsp.c
|
|||
|
||||
|
||||
|
||||
===== Handle As
|
||||
==== Handle As
|
||||
The **handle-as** provider lets you substitute the type of the property to a more high-level type.
|
||||
This typically happens when the property has a `java.lang.String` type, because you do not want your configuration classes to rely on classes that may not be on the classpath.
|
||||
This provider supports the following parameters:
|
||||
|
|
@ -546,7 +545,7 @@ It is actually used internally as a `org.springframework.core.io.Resource` but c
|
|||
|
||||
|
||||
|
||||
===== Logger Name
|
||||
==== Logger Name
|
||||
The **logger-name** provider auto-completes valid logger names and <<spring-boot-features.adoc#boot-features-custom-log-groups,logger groups>>.
|
||||
Typically, package and class names available in the current project can be auto-completed.
|
||||
If groups are enabled (default) and if a custom logger group is identified in the configuration, auto-completion for it should be provided.
|
||||
|
|
@ -632,7 +631,7 @@ As Spring Boot defines a few logger groups out-of-the-box, dedicated value hints
|
|||
|
||||
|
||||
|
||||
===== Spring Bean Reference
|
||||
==== Spring Bean Reference
|
||||
The **spring-bean-reference** provider auto-completes the beans that are defined in the configuration of the current project.
|
||||
This provider supports the following parameters:
|
||||
|
||||
|
|
@ -671,7 +670,7 @@ If you provide that hint, you still need to transform the bean name into an actu
|
|||
|
||||
|
||||
|
||||
===== Spring Profile Name
|
||||
==== Spring Profile Name
|
||||
The **spring-profile-name** provider auto-completes the Spring profiles that are defined in the configuration of the current project.
|
||||
|
||||
The following metadata snippet corresponds to the standard `spring.profiles.active` property that defines the name of the Spring profile(s) to enable:
|
||||
|
|
@ -693,7 +692,7 @@ The following metadata snippet corresponds to the standard `spring.profiles.acti
|
|||
|
||||
|
||||
[[configuration-metadata-annotation-processor]]
|
||||
=== Generating Your Own Metadata by Using the Annotation Processor
|
||||
== Generating Your Own Metadata by Using the Annotation Processor
|
||||
You can easily generate your own configuration metadata file from items annotated with `@ConfigurationProperties` by using the `spring-boot-configuration-processor` jar.
|
||||
The jar includes a Java annotation processor which is invoked as your project is compiled.
|
||||
To use the processor, include a dependency on `spring-boot-configuration-processor`.
|
||||
|
|
@ -812,7 +811,7 @@ You could also let the AspectJ plugin run all the processing and disable annotat
|
|||
|
||||
|
||||
[[configuration-metadata-nested-properties]]
|
||||
==== Nested Properties
|
||||
=== Nested Properties
|
||||
The annotation processor automatically considers inner classes as nested properties.
|
||||
Consider the following class:
|
||||
|
||||
|
|
@ -848,7 +847,7 @@ TIP: This has no effect on collections and maps, as those types are automaticall
|
|||
|
||||
|
||||
[[configuration-metadata-additional-metadata]]
|
||||
==== Adding Additional Metadata
|
||||
=== Adding Additional Metadata
|
||||
Spring Boot's configuration file handling is quite flexible, and it is often the case that properties may exist that are not bound to a `@ConfigurationProperties` bean.
|
||||
You may also need to tune some attributes of an existing key.
|
||||
To support such cases and let you provide custom "hints", the annotation processor automatically merges items from `META-INF/additional-spring-configuration-metadata.json` into the main metadata file.
|
||||
|
|
@ -1,9 +1,13 @@
|
|||
[appendix]
|
||||
[[appendix-dependency-versions]]
|
||||
== Dependency versions
|
||||
|
||||
[[dependency-versions]]
|
||||
= Dependency versions
|
||||
include::{asciidoc-sources-root}/attributes.adoc[]
|
||||
|
||||
This appendix provides details of the dependencies that are managed by Spring Boot.
|
||||
|
||||
[[dependency-versions-coordinates]]
|
||||
== Managed Dependency Coordinates
|
||||
|
||||
The following table provides details of all of the dependency versions that are provided by Spring Boot in its CLI (Command Line Interface), Maven dependency management, and Gradle plugin.
|
||||
When you declare a dependency on one of these artifacts without declaring a version, the version listed in the table is used.
|
||||
|
||||
|
|
@ -1,18 +1,17 @@
|
|||
[appendix]
|
||||
[[executable-jar]]
|
||||
== The Executable Jar Format
|
||||
|
||||
= The Executable Jar Format
|
||||
include::{asciidoc-sources-root}/attributes.adoc[]
|
||||
|
||||
The `spring-boot-loader` modules lets Spring Boot support executable jar and war files.
|
||||
If you use the Maven plugin or the Gradle plugin, executable jars are automatically generated, and you generally do not need to know the details of how they work.
|
||||
|
||||
If you need to create executable jars from a different build system or if you are just curious about the underlying technology, this section provides some background.
|
||||
If you need to create executable jars from a different build system or if you are just curious about the underlying technology, this appendix provides some background.
|
||||
|
||||
|
||||
|
||||
[[executable-jar-nested-jars]]
|
||||
=== Nested JARs
|
||||
== Nested JARs
|
||||
Java does not provide any standard way to load nested jar files (that is, jar files that are themselves contained within a jar).
|
||||
This can be problematic if you need to distribute a self-contained application that can be run from the command line without unpacking.
|
||||
|
||||
|
|
@ -25,7 +24,7 @@ Spring Boot takes a different approach and lets you actually nest jars directly.
|
|||
|
||||
|
||||
[[executable-jar-jar-file-structure]]
|
||||
==== The Executable Jar File Structure
|
||||
=== The Executable Jar File Structure
|
||||
Spring Boot Loader-compatible jar files should be structured in the following way:
|
||||
|
||||
[indent=0]
|
||||
|
|
@ -55,7 +54,7 @@ Dependencies should be placed in a nested `BOOT-INF/lib` directory.
|
|||
|
||||
|
||||
[[executable-jar-war-file-structure]]
|
||||
==== The Executable War File Structure
|
||||
=== The Executable War File Structure
|
||||
Spring Boot Loader-compatible war files should be structured in the following way:
|
||||
|
||||
[indent=0]
|
||||
|
|
@ -89,7 +88,7 @@ Any dependencies that are required when running embedded but are not required wh
|
|||
|
||||
|
||||
[[executable-jar-jarfile]]
|
||||
=== Spring Boot's "`JarFile`" Class
|
||||
== Spring Boot's "`JarFile`" Class
|
||||
The core class used to support loading nested jars is `org.springframework.boot.loader.jar.JarFile`.
|
||||
It lets you load jar content from a standard jar file or from nested child jar data.
|
||||
When first loaded, the location of each `JarEntry` is mapped to a physical file offset of the outer jar, as shown in the following example:
|
||||
|
|
@ -116,7 +115,7 @@ We do not need to unpack the archive, and we do not need to read all entry data
|
|||
|
||||
|
||||
[[executable-jar-jarfile-compatibility]]
|
||||
==== Compatibility with the Standard Java "`JarFile`"
|
||||
=== Compatibility with the Standard Java "`JarFile`"
|
||||
Spring Boot Loader strives to remain compatible with existing code and libraries.
|
||||
`org.springframework.boot.loader.jar.JarFile` extends from `java.util.jar.JarFile` and should work as a drop-in replacement.
|
||||
The `getURL()` method returns a `URL` that opens a connection compatible with `java.net.JarURLConnection` and can be used with Java's `URLClassLoader`.
|
||||
|
|
@ -124,7 +123,7 @@ The `getURL()` method returns a `URL` that opens a connection compatible with `j
|
|||
|
||||
|
||||
[[executable-jar-launching]]
|
||||
=== Launching Executable Jars
|
||||
== Launching Executable Jars
|
||||
The `org.springframework.boot.loader.Launcher` class is a special bootstrap class that is used as an executable jar's main entry point.
|
||||
It is the actual `Main-Class` in your jar file, and it is used to setup an appropriate `URLClassLoader` and ultimately call your `main()` method.
|
||||
|
||||
|
|
@ -139,7 +138,7 @@ You can add additional locations by setting an environment variable called `LOAD
|
|||
|
||||
|
||||
[[executable-jar-launcher-manifest]]
|
||||
==== Launcher Manifest
|
||||
=== Launcher Manifest
|
||||
You need to specify an appropriate `Launcher` as the `Main-Class` attribute of `META-INF/MANIFEST.MF`.
|
||||
The actual class that you want to launch (that is, the class that contains a `main` method) should be specified in the `Start-Class` attribute.
|
||||
|
||||
|
|
@ -165,7 +164,7 @@ The classpath is deduced from the nested jars.
|
|||
|
||||
|
||||
[[executable-jar-exploded-archives]]
|
||||
==== Exploded Archives
|
||||
=== Exploded Archives
|
||||
Certain PaaS implementations may choose to unpack archives before they run.
|
||||
For example, Cloud Foundry operates this way.
|
||||
You can run an unpacked archive by starting the appropriate launcher, as follows:
|
||||
|
|
@ -179,7 +178,7 @@ You can run an unpacked archive by starting the appropriate launcher, as follows
|
|||
|
||||
|
||||
[[executable-jar-property-launcher-features]]
|
||||
=== `PropertiesLauncher` Features
|
||||
== `PropertiesLauncher` Features
|
||||
`PropertiesLauncher` has a few special features that can be enabled with external properties (System properties, environment variables, manifest entries, or `loader.properties`).
|
||||
The following table describes these properties:
|
||||
|
||||
|
|
@ -263,7 +262,7 @@ The following rules apply to working with `PropertiesLauncher`:
|
|||
|
||||
|
||||
[[executable-jar-restrictions]]
|
||||
=== Executable Jar Restrictions
|
||||
== Executable Jar Restrictions
|
||||
You need to consider the following restrictions when working with a Spring Boot Loader packaged application:
|
||||
|
||||
|
||||
|
|
@ -286,7 +285,7 @@ For this reason, you should consider a different logging implementation.
|
|||
|
||||
|
||||
[[executable-jar-alternatives]]
|
||||
=== Alternative Single Jar Solutions
|
||||
== Alternative Single Jar Solutions
|
||||
If the preceding restrictions mean that you cannot use Spring Boot Loader, consider the following alternatives:
|
||||
|
||||
* https://maven.apache.org/plugins/maven-shade-plugin/[Maven Shade Plugin]
|
||||
|
|
@ -1,9 +1,13 @@
|
|||
[appendix]
|
||||
[[test-auto-configuration]]
|
||||
== Test Auto-configuration Annotations
|
||||
|
||||
= Test Auto-configuration Annotations
|
||||
include::{asciidoc-sources-root}/attributes.adoc[]
|
||||
|
||||
This appendix describes the `@…Test` auto-configuration annotations that Spring Boot provides to test slices of your application.
|
||||
|
||||
[[test-auto-configuration-slices]]
|
||||
== Test Slices
|
||||
|
||||
The following table lists the various `@…Test` annotations that can be used to test slices of your application and the auto-configuration that they import by default:
|
||||
|
||||
include::{generated-resources-root}/test-slice-auto-configuration.adoc[]
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[[appendix]]
|
||||
= Appendices
|
||||
|
||||
include::attributes.adoc[]
|
||||
|
||||
include::appendix/application-properties.adoc[]
|
||||
include::appendix/configuration-metadata.adoc[]
|
||||
include::appendix/auto-configuration-classes.adoc[]
|
||||
include::appendix/test-auto-configuration.adoc[]
|
||||
include::appendix/executable-jar-format.adoc[]
|
||||
include::appendix/dependency-versions.adoc[]
|
||||
|
|
@ -323,7 +323,7 @@ This section contains three examples of using `findmainclass`.
|
|||
[[build-tool-plugins-other-build-systems]]
|
||||
== Supporting Other Build Systems
|
||||
If you want to use a build tool other than Maven, Gradle, or Ant, you likely need to develop your own plugin.
|
||||
Executable jars need to follow a specific format and certain entries need to be written in an uncompressed form (see the "`<<appendix.adoc#executable-jar, executable jar format>>`" section in the appendix for details).
|
||||
Executable jars need to follow a specific format and certain entries need to be written in an uncompressed form (see the "`<<appendix-executable-jar-format.adoc#executable-jar, executable jar format>>`" section in the appendix for details).
|
||||
|
||||
The Spring Boot Maven and Gradle plugins both make use of `spring-boot-loader-tools` to actually generate jars.
|
||||
If you need to, you may use this library directly.
|
||||
|
|
@ -377,6 +377,6 @@ The following example shows a typical repackage implementation:
|
|||
[[build-tool-plugins-whats-next]]
|
||||
== What to Read Next
|
||||
If you are interested in how the build tool plugins work, you can look at the {spring-boot-code}/spring-boot-project/spring-boot-tools[`spring-boot-tools`] module on GitHub.
|
||||
More technical details of the executable jar format are covered in <<appendix.adoc#executable-jar,the appendix>>.
|
||||
More technical details of the executable jar format are covered in <<appendix-executable-jar-format#executable-jar,the appendix>>.
|
||||
|
||||
If you have specific build-related questions, you can check out the "`<<howto.adoc#howto, how-to>>`" guides.
|
||||
|
|
|
|||
|
|
@ -88,4 +88,4 @@ Finally, we have a few topics for more advanced users:
|
|||
|
||||
* *Spring Boot Applications Deployment:* <<deployment.adoc#cloud-deployment, Cloud Deployment>> | <<deployment.adoc#deployment-service, OS Service>>
|
||||
* *Build tool plugins:* <<build-tool-plugins.adoc#build-tool-plugins-maven-plugin, Maven>> | <<build-tool-plugins.adoc#build-tool-plugins-gradle-plugin, Gradle>>
|
||||
* *Appendix:* <<appendix.adoc#common-application-properties, Application Properties>> | <<appendix.adoc#auto-configuration-classes, Auto-configuration classes>> | <<appendix.adoc#executable-jar, Executable Jars>>
|
||||
* *Appendix:* <<appendix-application-properties.adoc#common-application-properties,Application Properties>> | <<appendix-configuration-metadata.adoc#configuration-metadata,Configuration Metadata>> | <<appendix-auto-configuration-classes.adoc#auto-configuration-classes,Auto-configuration Classes>> | <<appendix-test-auto-configuration.adoc#test-auto-configuration,Test Auto-configuration Annotations>> | <<appendix-executable-jar-format.adoc#executable-jar,Executable Jars>> | <<appendix-dependency-versions.adoc#appendex-dependency-versions,Dependency Versions>>
|
||||
|
|
|
|||
|
|
@ -658,7 +658,7 @@ An uber jar packages all the classes from all the application's dependencies int
|
|||
The problem with this approach is that it becomes hard to see which libraries are in your application.
|
||||
It can also be problematic if the same filename is used (but with different content) in multiple jars.
|
||||
|
||||
Spring Boot takes a <<appendix.adoc#executable-jar, different approach>> and lets you actually nest jars directly.
|
||||
Spring Boot takes a <<appendix-executable-jar-format.adoc#executable-jar, different approach>> and lets you actually nest jars directly.
|
||||
****
|
||||
|
||||
To create an executable jar, we need to add the `spring-boot-maven-plugin` to our `pom.xml`.
|
||||
|
|
|
|||
|
|
@ -397,7 +397,7 @@ There is not (and technically cannot be) an exhaustive list of all supported pro
|
|||
|
||||
A running application with the Actuator features has a `configprops` endpoint that shows all the bound and bindable properties available through `@ConfigurationProperties`.
|
||||
|
||||
The appendix includes an <<appendix.adoc#common-application-properties, `application.properties`>> example with a list of the most common properties supported by Spring Boot.
|
||||
The appendix includes an <<application-properties.adoc#common-application-properties, `application.properties`>> example with a list of the most common properties supported by Spring Boot.
|
||||
The definitive list comes from searching the source code for `@ConfigurationProperties` and `@Value` annotations as well as the occasional use of `Binder`.
|
||||
For more about the exact ordering of loading properties, see "<<spring-boot-features#boot-features-external-config>>".
|
||||
|
||||
|
|
@ -2435,7 +2435,7 @@ If your application contains classes that you want to share with other projects,
|
|||
The separate module can then be depended upon by your application and other projects.
|
||||
|
||||
If you cannot rearrange your code as recommended above, Spring Boot's Maven and Gradle plugins must be configured to produce a separate artifact that is suitable for use as a dependency.
|
||||
The executable archive cannot be used as a dependency as the <<appendix.adoc#executable-jar-jar-file-structure,executable jar format>> packages application classes in `BOOT-INF/classes`.
|
||||
The executable archive cannot be used as a dependency as the <<appendix-executable-jar-format.adoc#executable-jar-jar-file-structure,executable jar format>> packages application classes in `BOOT-INF/classes`.
|
||||
This means that they cannot be found when the executable jar is used as a dependency.
|
||||
|
||||
To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified.
|
||||
|
|
|
|||
|
|
@ -16,4 +16,13 @@ The reference documentation consists of the following sections:
|
|||
<<spring-boot-cli.adoc#cli,Spring Boot CLI>> :: Installing the CLI, Using the CLI, Configuring the CLI, and more.
|
||||
<<build-tool-plugins.adoc#build-tool-plugins,Build Tool Plugins>> :: Maven Plugin, Gradle Plugin, Antlib, and more.
|
||||
<<howto.adoc#howto,"`How-to`" Guides>> :: Application Development, Configuration, Embedded Servers, Data Access, and many more.
|
||||
<<appendix.adoc#appendix,Appendices>> :: Properties, Metadata, Configuration, Dependencies, and more.
|
||||
|
||||
The reference documentation has the following appendices:
|
||||
|
||||
[horizontal]
|
||||
<<appendix-application-properties.adoc#common-application-properties,Application Properties>> :: Common application properties that can be used to configure your application.
|
||||
<<appendix-configuration-metadata.adoc#configuration-metadata,Configuration Metadata>> :: Metadata used to describe configuration properties.
|
||||
<<appendix-auto-configuration-classes.adoc#auto-configuration-classes,Auto-configuration Classes>> :: Auto-configuration classes provided by Spring Boot.
|
||||
<<appendix-test-auto-configuration.adoc#test-auto-configuration,Test Auto-configuration Annotations>> :: Test-autoconfiguration annotations used to test slices of your application.
|
||||
<<appendix-executable-jar-format.adoc#executable-jar,Executable Jars>> :: Spring Boot's executable jars, their launchers, and their format.
|
||||
<<appendix-dependency-versions.adoc#appendex-dependency-versions,Dependency Versions>> :: Details of the dependencies that are managed by Spring Boot.
|
||||
|
|
|
|||
|
|
@ -14,4 +14,15 @@ include::deployment.adoc[leveloffset=+1]
|
|||
include::spring-boot-cli.adoc[leveloffset=+1]
|
||||
include::build-tool-plugins.adoc[leveloffset=+1]
|
||||
include::howto.adoc[leveloffset=+1]
|
||||
include::appendix.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
|
||||
[[appendix]]
|
||||
== Appendices
|
||||
|
||||
include::appendix-application-properties.adoc[leveloffset=+2]
|
||||
include::appendix-configuration-metadata.adoc[leveloffset=+2]
|
||||
include::appendix-auto-configuration-classes.adoc[leveloffset=+2]
|
||||
include::appendix-test-auto-configuration.adoc[leveloffset=+2]
|
||||
include::appendix-executable-jar-format.adoc[leveloffset=+2]
|
||||
include::appendix-dependency-versions.adoc[leveloffset=+2]
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ Doing so consults Spring Boot's default dependency metadata to deduce the artifa
|
|||
|
||||
NOTE: The default metadata is tied to the version of the CLI that you use.
|
||||
It changes only when you move to a new version of the CLI, putting you in control of when the versions of your dependencies may change.
|
||||
A table showing the dependencies and their versions that are included in the default metadata can be found in the <<appendix.adoc#appendix-dependency-versions,appendix>>.
|
||||
A table showing the dependencies and their versions that are included in the default metadata can be found in the <<appendix-dependency-versions.adoc#appendix-dependency-versions,appendix>>.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -992,7 +992,7 @@ To work with `@ConfigurationProperties` beans, you can inject them in the same w
|
|||
----
|
||||
|
||||
TIP: Using `@ConfigurationProperties` also lets you generate metadata files that can be used by IDEs to offer auto-completion for your own keys.
|
||||
See the <<appendix.adoc#configuration-metadata,appendix>> for details.
|
||||
See the <<appendix-configuration-metadata.adoc#configuration-metadata,appendix>> for details.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1372,7 +1372,7 @@ The following table summarizes the features that are supported by `@Configuratio
|
|||
| Yes
|
||||
| No
|
||||
|
||||
| <<appendix.adoc#configuration-metadata,Meta-data support>>
|
||||
| <<appendix-configuration-metadata.adoc#configuration-metadata,Meta-data support>>
|
||||
| Yes
|
||||
| No
|
||||
|
||||
|
|
@ -6183,7 +6183,7 @@ To test that object JSON serialization and deserialization is working as expecte
|
|||
* `Gson`
|
||||
* `Jsonb`
|
||||
|
||||
TIP: A list of the auto-configurations that are enabled by `@JsonTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configurations that are enabled by `@JsonTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
If you need to configure elements of the auto-configuration, you can use the `@AutoConfigureJsonTesters` annotation.
|
||||
|
||||
|
|
@ -6252,7 +6252,7 @@ To test whether Spring MVC controllers are working as expected, use the `@WebMvc
|
|||
`@WebMvcTest` auto-configures the Spring MVC infrastructure and limits scanned beans to `@Controller`, `@ControllerAdvice`, `@JsonComponent`, `Converter`, `GenericConverter`, `Filter`, `HandlerInterceptor`, `WebMvcConfigurer`, and `HandlerMethodArgumentResolver`.
|
||||
Regular `@Component` beans are not scanned when using this annotation.
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@WebMvcTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@WebMvcTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
TIP: If you need to register extra components, such as the Jackson `Module`, you can import additional configuration classes by using `@Import` on your test.
|
||||
|
||||
|
|
@ -6352,7 +6352,7 @@ To test that {spring-framework-docs}/web-reactive.html[Spring WebFlux] controlle
|
|||
`@WebFluxTest` auto-configures the Spring WebFlux infrastructure and limits scanned beans to `@Controller`, `@ControllerAdvice`, `@JsonComponent`, `Converter`, `GenericConverter`, `WebFilter`, and `WebFluxConfigurer`.
|
||||
Regular `@Component` beans are not scanned when the `@WebFluxTest` annotation is used.
|
||||
|
||||
TIP: A list of the auto-configurations that are enabled by `@WebFluxTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configurations that are enabled by `@WebFluxTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
TIP: If you need to register extra components, such as Jackson `Module`, you can import additional configuration classes using `@Import` on your test.
|
||||
|
||||
|
|
@ -6413,7 +6413,7 @@ By default, it scans for `@Entity` classes and configures Spring Data JPA reposi
|
|||
If an embedded database is available on the classpath, it configures one as well.
|
||||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataJpaTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataJpaTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
By default, data JPA tests are transactional and roll back at the end of each test.
|
||||
See the {spring-framework-docs}testing.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
|
||||
|
|
@ -6487,7 +6487,7 @@ If, however, you prefer to run tests against a real database you can use the `@A
|
|||
By default, it configures an in-memory embedded database and a `JdbcTemplate`.
|
||||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
|
||||
TIP: A list of the auto-configurations that are enabled by `@JdbcTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configurations that are enabled by `@JdbcTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
By default, JDBC tests are transactional and roll back at the end of each test.
|
||||
See the {spring-framework-docs}testing.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
|
||||
|
|
@ -6518,7 +6518,7 @@ If you prefer your test to run against a real database, you can use the `@AutoCo
|
|||
By default, it configures an in-memory embedded database, a `JdbcTemplate`, and Spring Data JDBC repositories.
|
||||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
|
||||
TIP: A list of the auto-configurations that are enabled by `@DataJdbcTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configurations that are enabled by `@DataJdbcTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
By default, Data JDBC tests are transactional and roll back at the end of each test.
|
||||
See the {spring-framework-docs}testing.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
|
||||
|
|
@ -6537,7 +6537,7 @@ If you want to replace it with an in-memory database, you can use `@AutoConfigur
|
|||
(For more about using jOOQ with Spring Boot, see "<<boot-features-jooq>>", earlier in this chapter.)
|
||||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
|
||||
TIP: A list of the auto-configurations that are enabled by `@JooqTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configurations that are enabled by `@JooqTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
`@JooqTest` configures a `DSLContext`.
|
||||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
|
|
@ -6569,7 +6569,7 @@ By default, it configures an in-memory embedded MongoDB (if available), configur
|
|||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
(For more about using MongoDB with Spring Boot, see "<<boot-features-mongodb>>", earlier in this chapter.)
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataMongoTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataMongoTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
The following class shows the `@DataMongoTest` annotation in use:
|
||||
|
||||
|
|
@ -6612,7 +6612,7 @@ By default, it uses an in-memory embedded Neo4j (if the embedded driver is avail
|
|||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
(For more about using Neo4J with Spring Boot, see "<<boot-features-neo4j>>", earlier in this chapter.)
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataNeo4jTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataNeo4jTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
The following example shows a typical setup for using Neo4J tests in Spring Boot:
|
||||
|
||||
|
|
@ -6657,7 +6657,7 @@ By default, it scans for `@RedisHash` classes and configures Spring Data Redis r
|
|||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
(For more about using Redis with Spring Boot, see "<<boot-features-redis>>", earlier in this chapter.)
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataRedisTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataRedisTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
The following example shows the `@DataRedisTest` annotation in use:
|
||||
|
||||
|
|
@ -6685,7 +6685,7 @@ By default, it configures an in-memory embedded LDAP (if available), configures
|
|||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
(For more about using LDAP with Spring Boot, see "<<boot-features-ldap>>", earlier in this chapter.)
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataLdapTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@DataLdapTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
The following example shows the `@DataLdapTest` annotation in use:
|
||||
|
||||
|
|
@ -6727,7 +6727,7 @@ You can use the `@RestClientTest` annotation to test REST clients.
|
|||
By default, it auto-configures Jackson, GSON, and Jsonb support, configures a `RestTemplateBuilder`, and adds support for `MockRestServiceServer`.
|
||||
Regular `@Component` beans are not loaded into the `ApplicationContext`.
|
||||
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@RestClientTest` can be <<appendix.adoc#test-auto-configuration,found in the appendix>>.
|
||||
TIP: A list of the auto-configuration settings that are enabled by `@RestClientTest` can be <<appendix-test-auto-configuration.adoc#test-auto-configuration,found in the appendix>>.
|
||||
|
||||
The specific beans that you want to test should be specified by using the `value` or `components` attribute of `@RestClientTest`, as shown in the following example:
|
||||
|
||||
|
|
@ -7433,7 +7433,7 @@ Here are some rules we follow internally to make sure descriptions are consisten
|
|||
* Use `java.time.Duration` rather than `long` and describe the default unit if it differs from milliseconds, e.g. "If a duration suffix is not specified, seconds will be used".
|
||||
* Do not provide the default value in the description unless it has to be determined at runtime.
|
||||
|
||||
Make sure to <<appendix.adoc#configuration-metadata-annotation-processor,trigger meta-data generation>> so that IDE assistance is available for your keys as well.
|
||||
Make sure to <<appendix-configuration-metadata.adoc#configuration-metadata-annotation-processor,trigger meta-data generation>> so that IDE assistance is available for your keys as well.
|
||||
You may want to review the generated metadata (`META-INF/spring-configuration-metadata.json`) to make sure your keys are properly documented.
|
||||
Using your own starter in a compatible IDE is also a good idea to validate that quality of the metadata.
|
||||
|
||||
|
|
@ -7618,7 +7618,7 @@ data class MyService(
|
|||
)
|
||||
----
|
||||
|
||||
TIP: To generate <<appendix.adoc#configuration-metadata-annotation-processor,your own metadata>> using the annotation processor, {kotlin-docs}kapt.html[`kapt` should be configured] with the `spring-boot-configuration-processor` dependency.
|
||||
TIP: To generate <<appendix-configuration-metadata.adoc#configuration-metadata-annotation-processor,your own metadata>> using the annotation processor, {kotlin-docs}kapt.html[`kapt` should be configured] with the `spring-boot-configuration-processor` dependency.
|
||||
Note that some features (such as detecting the default value or deperecated items) are not working due to limitations in the model kapt provides.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue