Don't use monospacing in documentation headings
Closes gh-20875
This commit is contained in:
parent
e17d4be484
commit
d9fb4dd477
|
@ -6,7 +6,7 @@ The `configprops` endpoint provides information about the application's `@Config
|
||||||
|
|
||||||
|
|
||||||
[[configprops-retrieving]]
|
[[configprops-retrieving]]
|
||||||
== Retrieving the `@ConfigurationProperties` Bean
|
== Retrieving the @ConfigurationProperties Bean
|
||||||
|
|
||||||
To retrieve the `@ConfigurationProperties` beans, make a `GET` request to `/actuator/configprops`, as shown in the following curl-based example:
|
To retrieve the `@ConfigurationProperties` beans, make a `GET` request to `/actuator/configprops`, as shown in the following curl-based example:
|
||||||
|
|
||||||
|
|
|
@ -28,7 +28,7 @@ Spring Boot provides `build` and `git` contributions.
|
||||||
|
|
||||||
|
|
||||||
[[info-retrieving-response-structure-build]]
|
[[info-retrieving-response-structure-build]]
|
||||||
==== `build` Response Structure
|
==== Build Response Structure
|
||||||
|
|
||||||
The following table describe the structure of the `build` section of the response:
|
The following table describe the structure of the `build` section of the response:
|
||||||
|
|
||||||
|
@ -38,7 +38,7 @@ include::{snippets}/info/response-fields-beneath-build.adoc[]
|
||||||
|
|
||||||
|
|
||||||
[[info-retrieving-response-structure-git]]
|
[[info-retrieving-response-structure-git]]
|
||||||
==== `git` Response Structure
|
==== Git Response Structure
|
||||||
|
|
||||||
The following table describes the structure of the `git` section of the response:
|
The following table describes the structure of the `git` section of the response:
|
||||||
|
|
||||||
|
|
|
@ -10,7 +10,7 @@ Remember to also look at the conditions report in your application for more deta
|
||||||
|
|
||||||
|
|
||||||
[[auto-configuration-classes-from-autoconfigure-module]]
|
[[auto-configuration-classes-from-autoconfigure-module]]
|
||||||
== `spring-boot-autoconfigure`
|
== spring-boot-autoconfigure
|
||||||
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
|
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
|
||||||
|
|
||||||
include::auto-configuration-classes/spring-boot-autoconfigure.adoc[]
|
include::auto-configuration-classes/spring-boot-autoconfigure.adoc[]
|
||||||
|
@ -18,7 +18,7 @@ include::auto-configuration-classes/spring-boot-autoconfigure.adoc[]
|
||||||
|
|
||||||
|
|
||||||
[[auto-configuration-classes-from-actuator]]
|
[[auto-configuration-classes-from-actuator]]
|
||||||
== `spring-boot-actuator-autoconfigure`
|
== spring-boot-actuator-autoconfigure
|
||||||
The following auto-configuration classes are from the `spring-boot-actuator-autoconfigure` module:
|
The following auto-configuration classes are from the `spring-boot-actuator-autoconfigure` module:
|
||||||
|
|
||||||
include::auto-configuration-classes/spring-boot-actuator-autoconfigure.adoc[]
|
include::auto-configuration-classes/spring-boot-actuator-autoconfigure.adoc[]
|
||||||
|
|
|
@ -231,7 +231,7 @@ The classpath is deduced from the nested jars.
|
||||||
|
|
||||||
|
|
||||||
[[executable-jar-property-launcher-features]]
|
[[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`).
|
`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:
|
The following table describes these properties:
|
||||||
|
|
||||||
|
|
|
@ -68,7 +68,7 @@ Once the `spring-boot-antlib` namespace has been declared, the following additio
|
||||||
|
|
||||||
|
|
||||||
[[spring-boot-ant-exejar]]
|
[[spring-boot-ant-exejar]]
|
||||||
==== `spring-boot:exejar`
|
==== Using the "`exejar`" Task
|
||||||
You can use the `exejar` task to create a Spring Boot executable jar.
|
You can use the `exejar` task to create a Spring Boot executable jar.
|
||||||
The following attributes are supported by the task:
|
The following attributes are supported by the task:
|
||||||
|
|
||||||
|
@ -136,7 +136,7 @@ This section shows two examples of Ant tasks.
|
||||||
|
|
||||||
|
|
||||||
[[spring-boot-ant-findmainclass]]
|
[[spring-boot-ant-findmainclass]]
|
||||||
=== `spring-boot:findmainclass`
|
=== Using the "`findmainclass`" Task
|
||||||
The `findmainclass` task is used internally by `exejar` to locate a class declaring a `main`.
|
The `findmainclass` task is used internally by `exejar` to locate a class declaring a `main`.
|
||||||
If necessary, you can also use this task directly in your build.
|
If necessary, you can also use this task directly in your build.
|
||||||
The following attributes are supported:
|
The following attributes are supported:
|
||||||
|
|
|
@ -505,7 +505,7 @@ Spring Boot application can be easily started as Unix/Linux services by using ei
|
||||||
|
|
||||||
|
|
||||||
[[deployment-initd-service]]
|
[[deployment-initd-service]]
|
||||||
==== Installation as an `init.d` Service (System V)
|
==== Installation as an init.d Service (System V)
|
||||||
If you configured Spring Boot's Maven or Gradle plugin to generate a <<deployment-install, fully executable jar>>, and you do not use a custom `embeddedLaunchScript`, your application can be used as an `init.d` service.
|
If you configured Spring Boot's Maven or Gradle plugin to generate a <<deployment-install, fully executable jar>>, and you do not use a custom `embeddedLaunchScript`, your application can be used as an `init.d` service.
|
||||||
To do so, symlink the jar to `init.d` to support the standard `start`, `stop`, `restart`, and `status` commands.
|
To do so, symlink the jar to `init.d` to support the standard `start`, `stop`, `restart`, and `status` commands.
|
||||||
|
|
||||||
|
@ -543,7 +543,7 @@ For example, on Debian, you could use the following command:
|
||||||
|
|
||||||
|
|
||||||
[[deployment-initd-service-securing]]
|
[[deployment-initd-service-securing]]
|
||||||
===== Securing an `init.d` Service
|
===== Securing an init.d Service
|
||||||
NOTE: The following is a set of guidelines on how to secure a Spring Boot application that runs as an init.d service.
|
NOTE: The following is a set of guidelines on how to secure a Spring Boot application that runs as an init.d service.
|
||||||
It is not intended to be an exhaustive list of everything that should be done to harden an application and the environment in which it runs.
|
It is not intended to be an exhaustive list of everything that should be done to harden an application and the environment in which it runs.
|
||||||
|
|
||||||
|
@ -594,7 +594,7 @@ Use `chmod` so that the file can only be read by the owner and use `chown` to ma
|
||||||
|
|
||||||
|
|
||||||
[[deployment-systemd-service]]
|
[[deployment-systemd-service]]
|
||||||
==== Installation as a `systemd` Service
|
==== Installation as a systemd Service
|
||||||
`systemd` is the successor of the System V init system and is now being used by many modern Linux distributions.
|
`systemd` is the successor of the System V init system and is now being used by many modern Linux distributions.
|
||||||
Although you can continue to use `init.d` scripts with `systemd`, it is also possible to launch Spring Boot applications by using `systemd` '`service`' scripts.
|
Although you can continue to use `init.d` scripts with `systemd`, it is also possible to launch Spring Boot applications by using `systemd` '`service`' scripts.
|
||||||
|
|
||||||
|
|
|
@ -218,7 +218,7 @@ To use Spring property placeholders together with automatic expansion, escape th
|
||||||
|
|
||||||
|
|
||||||
[[howto-externalize-configuration]]
|
[[howto-externalize-configuration]]
|
||||||
=== Externalize the Configuration of `SpringApplication`
|
=== Externalize the Configuration of SpringApplication
|
||||||
A `SpringApplication` has bean properties (mainly setters), so you can use its Java API as you create the application to modify its behavior.
|
A `SpringApplication` has bean properties (mainly setters), so you can use its Java API as you create the application to modify its behavior.
|
||||||
Alternatively, you can externalize the configuration by setting properties in `+spring.main.*+`.
|
Alternatively, you can externalize the configuration by setting properties in `+spring.main.*+`.
|
||||||
For example, in `application.properties`, you might have the following settings:
|
For example, in `application.properties`, you might have the following settings:
|
||||||
|
@ -1831,7 +1831,7 @@ If you use Spring Data, you need to configure `@EnableJpaRepositories` according
|
||||||
|
|
||||||
|
|
||||||
[[howto-use-traditional-persistence-xml]]
|
[[howto-use-traditional-persistence-xml]]
|
||||||
=== Use a Traditional `persistence.xml` File
|
=== Use a Traditional persistence.xml File
|
||||||
Spring Boot will not search for or use a `META-INF/persistence.xml` by default.
|
Spring Boot will not search for or use a `META-INF/persistence.xml` by default.
|
||||||
If you prefer to use a traditional `persistence.xml`, you need to define your own `@Bean` of type `LocalEntityManagerFactoryBean` (with an ID of '`entityManagerFactory`') and set the persistence unit name there.
|
If you prefer to use a traditional `persistence.xml`, you need to define your own `@Bean` of type `LocalEntityManagerFactoryBean` (with an ID of '`entityManagerFactory`') and set the persistence unit name there.
|
||||||
|
|
||||||
|
@ -2611,7 +2611,7 @@ See {spring-boot-maven-plugin-docs}#run-example-debug[this example] for more det
|
||||||
|
|
||||||
|
|
||||||
[[howto-build-an-executable-archive-with-ant]]
|
[[howto-build-an-executable-archive-with-ant]]
|
||||||
=== Build an Executable Archive from Ant without Using `spring-boot-antlib`
|
=== Build an Executable Archive from Ant without Using spring-boot-antlib
|
||||||
To build with Ant, you need to grab dependencies, compile, and then create a jar or war archive.
|
To build with Ant, you need to grab dependencies, compile, and then create a jar or war archive.
|
||||||
To make it executable, you can either use the `spring-boot-antlib` module or you can follow these instructions:
|
To make it executable, you can either use the `spring-boot-antlib` module or you can follow these instructions:
|
||||||
|
|
||||||
|
|
|
@ -408,7 +408,7 @@ You can mix class declarations with `beans{}` in the same file as long as they s
|
||||||
|
|
||||||
|
|
||||||
[[cli-maven-settings]]
|
[[cli-maven-settings]]
|
||||||
== Configuring the CLI with `settings.xml`
|
== Configuring the CLI with settings.xml
|
||||||
The Spring Boot CLI uses Aether, Maven's dependency resolution engine, to resolve dependencies.
|
The Spring Boot CLI uses Aether, Maven's dependency resolution engine, to resolve dependencies.
|
||||||
The CLI makes use of the Maven configuration found in `~/.m2/settings.xml` to configure Aether.
|
The CLI makes use of the Maven configuration found in `~/.m2/settings.xml` to configure Aether.
|
||||||
The following configuration settings are honored by the CLI:
|
The following configuration settings are honored by the CLI:
|
||||||
|
|
|
@ -1024,7 +1024,7 @@ TIP: If you have more than one constructor for your class you can also use `@Con
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-external-config-enabling]]
|
[[boot-features-external-config-enabling]]
|
||||||
==== Enabling `@ConfigurationProperties`-annotated types
|
==== Enabling @ConfigurationProperties-annotated types
|
||||||
Spring Boot provides infrastructure to bind `@ConfigurationProperties` types and register them as beans.
|
Spring Boot provides infrastructure to bind `@ConfigurationProperties` types and register them as beans.
|
||||||
You can either enable configuration properties on a class-by-class basis or enable configuration property scanning that works in a similar manner to component scanning.
|
You can either enable configuration properties on a class-by-class basis or enable configuration property scanning that works in a similar manner to component scanning.
|
||||||
|
|
||||||
|
@ -1068,7 +1068,7 @@ If you still want to inject other beans using the constructor, the configuration
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-external-config-using]]
|
[[boot-features-external-config-using]]
|
||||||
==== Using `@ConfigurationProperties`-annotated types
|
==== Using @ConfigurationProperties-annotated types
|
||||||
This style of configuration works particularly well with the `SpringApplication` external YAML configuration, as shown in the following example:
|
This style of configuration works particularly well with the `SpringApplication` external YAML configuration, as shown in the following example:
|
||||||
|
|
||||||
[source,yaml,indent=0]
|
[source,yaml,indent=0]
|
||||||
|
@ -3133,8 +3133,9 @@ Spring Boot will auto-configure the Spring Messaging infrastructure for RSocket.
|
||||||
This means that Spring Boot will create a `RSocketMessageHandler` bean that will handle RSocket requests to your application.
|
This means that Spring Boot will create a `RSocketMessageHandler` bean that will handle RSocket requests to your application.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-rsocket-requester]]
|
[[boot-features-rsocket-requester]]
|
||||||
=== Calling RSocket Services with `RSocketRequester`
|
=== Calling RSocket Services with RSocketRequester
|
||||||
Once the `RSocket` channel is established between server and client, any party can send or receive requests to the other.
|
Once the `RSocket` channel is established between server and client, any party can send or receive requests to the other.
|
||||||
|
|
||||||
As a server, you can get injected with an `RSocketRequester` instance on any handler method of an RSocket `@Controller`.
|
As a server, you can get injected with an `RSocketRequester` instance on any handler method of an RSocket `@Controller`.
|
||||||
|
@ -5645,7 +5646,7 @@ spring.kafka.bootstrap-servers=${spring.embedded.kafka.brokers}
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-resttemplate]]
|
[[boot-features-resttemplate]]
|
||||||
== Calling REST Services with `RestTemplate`
|
== Calling REST Services with RestTemplate
|
||||||
If you need to call remote REST services from your application, you can use the Spring Framework's {spring-framework-api}/web/client/RestTemplate.html[`RestTemplate`] class.
|
If you need to call remote REST services from your application, you can use the Spring Framework's {spring-framework-api}/web/client/RestTemplate.html[`RestTemplate`] class.
|
||||||
Since `RestTemplate` instances often need to be customized before being used, Spring Boot does not provide any single auto-configured `RestTemplate` bean.
|
Since `RestTemplate` instances often need to be customized before being used, Spring Boot does not provide any single auto-configured `RestTemplate` bean.
|
||||||
It does, however, auto-configure a `RestTemplateBuilder`, which can be used to create `RestTemplate` instances when needed.
|
It does, however, auto-configure a `RestTemplateBuilder`, which can be used to create `RestTemplate` instances when needed.
|
||||||
|
@ -5699,7 +5700,7 @@ Doing so switches off the auto-configuration of a `RestTemplateBuilder` and prev
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-webclient]]
|
[[boot-features-webclient]]
|
||||||
== Calling REST Services with `WebClient`
|
== Calling REST Services with WebClient
|
||||||
If you have Spring WebFlux on your classpath, you can also choose to use `WebClient` to call remote REST services.
|
If you have Spring WebFlux on your classpath, you can also choose to use `WebClient` to call remote REST services.
|
||||||
Compared to `RestTemplate`, this client has a more functional feel and is fully reactive.
|
Compared to `RestTemplate`, this client has a more functional feel and is fully reactive.
|
||||||
You can learn more about the `WebClient` in the dedicated {spring-framework-docs}web-reactive.html#webflux-client[section in the Spring Framework docs].
|
You can learn more about the `WebClient` in the dedicated {spring-framework-docs}web-reactive.html#webflux-client[section in the Spring Framework docs].
|
||||||
|
@ -7414,7 +7415,7 @@ To do so, configure their location, as shown in the following example:
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-webservices-template]]
|
[[boot-features-webservices-template]]
|
||||||
=== Calling Web Services with `WebServiceTemplate`
|
=== Calling Web Services with WebServiceTemplate
|
||||||
If you need to call remote Web services from your application, you can use the {spring-webservices-docs}#client-web-service-template[`WebServiceTemplate`] class.
|
If you need to call remote Web services from your application, you can use the {spring-webservices-docs}#client-web-service-template[`WebServiceTemplate`] class.
|
||||||
Since `WebServiceTemplate` instances often need to be customized before being used, Spring Boot does not provide any single auto-configured `WebServiceTemplate` bean.
|
Since `WebServiceTemplate` instances often need to be customized before being used, Spring Boot does not provide any single auto-configured `WebServiceTemplate` bean.
|
||||||
It does, however, auto-configure a `WebServiceTemplateBuilder`, which can be used to create `WebServiceTemplate` instances when needed.
|
It does, however, auto-configure a `WebServiceTemplateBuilder`, which can be used to create `WebServiceTemplate` instances when needed.
|
||||||
|
@ -7751,7 +7752,7 @@ Using your own starter in a compatible IDE is also a good idea to validate that
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-custom-starter-module-autoconfigure]]
|
[[boot-features-custom-starter-module-autoconfigure]]
|
||||||
==== `autoconfigure` Module
|
==== The "`autoconfigure`" Module
|
||||||
The `autoconfigure` module contains everything that is necessary to get started with the library.
|
The `autoconfigure` module contains everything that is necessary to get started with the library.
|
||||||
It may also contain configuration key definitions (such as `@ConfigurationProperties`) and any callback interface that can be used to further customize how the components are initialized.
|
It may also contain configuration key definitions (such as `@ConfigurationProperties`) and any callback interface that can be used to further customize how the components are initialized.
|
||||||
|
|
||||||
|
@ -7915,7 +7916,7 @@ TIP: `org.jetbrains.kotlinx:kotlinx-coroutines-reactor` dependency is provided b
|
||||||
|
|
||||||
|
|
||||||
[[boot-features-kotlin-configuration-properties]]
|
[[boot-features-kotlin-configuration-properties]]
|
||||||
=== `@ConfigurationProperties`
|
=== @ConfigurationProperties
|
||||||
`@ConfigurationProperties` when used in combination with <<boot-features-external-config-constructor-binding,`@ConstructorBinding`>> supports classes with immutable `val` properties as shown in the following example:
|
`@ConfigurationProperties` when used in combination with <<boot-features-external-config-constructor-binding,`@ConstructorBinding`>> supports classes with immutable `val` properties as shown in the following example:
|
||||||
|
|
||||||
[source,kotlin,indent=0]
|
[source,kotlin,indent=0]
|
||||||
|
|
|
@ -247,7 +247,7 @@ include::../gradle/packaging/boot-jar-custom-launch-script.gradle.kts[tags=custo
|
||||||
|
|
||||||
|
|
||||||
[[packaging-executable-configuring-properties-launcher]]
|
[[packaging-executable-configuring-properties-launcher]]
|
||||||
==== Using the `PropertiesLauncher`
|
==== Using the PropertiesLauncher
|
||||||
To use the `PropertiesLauncher` to launch an executable jar or war, configure the task's manifest to set the `Main-Class` attribute:
|
To use the `PropertiesLauncher` to launch an executable jar or war, configure the task's manifest to set the `Main-Class` attribute:
|
||||||
|
|
||||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||||
|
|
|
@ -4,7 +4,7 @@
|
||||||
|
|
||||||
|
|
||||||
[[publishing-your-application-maven]]
|
[[publishing-your-application-maven]]
|
||||||
=== Publishing with the `maven` Plugin
|
=== Publishing with the Maven Plugin
|
||||||
When the {maven-plugin}[`maven` plugin] is applied, an `Upload` task for the `bootArchives` configuration named `uploadBootArchives` is automatically created.
|
When the {maven-plugin}[`maven` plugin] is applied, an `Upload` task for the `bootArchives` configuration named `uploadBootArchives` is automatically created.
|
||||||
By default, the `bootArchives` configuration contains the archive produced by the `bootJar` or `bootWar` task.
|
By default, the `bootArchives` configuration contains the archive produced by the `bootJar` or `bootWar` task.
|
||||||
The `uploadBootArchives` task can be configured to publish the archive to a Maven repository:
|
The `uploadBootArchives` task can be configured to publish the archive to a Maven repository:
|
||||||
|
@ -24,7 +24,7 @@ include::../gradle/publishing/maven.gradle.kts[tags=upload]
|
||||||
|
|
||||||
|
|
||||||
[[publishing-your-application-maven-publish]]
|
[[publishing-your-application-maven-publish]]
|
||||||
=== Publishing with the `maven-publish` Plugin
|
=== Publishing with the Maven-publish Plugin
|
||||||
To publish your Spring Boot jar or war, add it to the publication using the `artifact` method on `MavenPublication`.
|
To publish your Spring Boot jar or war, add it to the publication using the `artifact` method on `MavenPublication`.
|
||||||
Pass the task that produces that artifact that you wish to publish to the `artifact` method.
|
Pass the task that produces that artifact that you wish to publish to the `artifact` method.
|
||||||
For example, to publish the artifact produced by the default `bootJar` task:
|
For example, to publish the artifact produced by the default `bootJar` task:
|
||||||
|
@ -44,7 +44,7 @@ include::../gradle/publishing/maven-publish.gradle.kts[tags=publishing]
|
||||||
|
|
||||||
|
|
||||||
[[publishing-your-application-distribution]]
|
[[publishing-your-application-distribution]]
|
||||||
=== Distributing with the `application` Plugin
|
=== Distributing with the Application Plugin
|
||||||
When the {application-plugin}[`application` plugin] is applied a distribution named `boot` is created.
|
When the {application-plugin}[`application` plugin] is applied a distribution named `boot` is created.
|
||||||
This distribution contains the archive produced by the `bootJar` or `bootWar` task and scripts to launch it on Unix-like platforms and Windows.
|
This distribution contains the archive produced by the `bootJar` or `bootWar` task and scripts to launch it on Unix-like platforms and Windows.
|
||||||
Zip and tar distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively.
|
Zip and tar distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively.
|
||||||
|
|
|
@ -6,7 +6,7 @@ This section describes those changes.
|
||||||
|
|
||||||
|
|
||||||
[[reacting-to-other-plugins-java]]
|
[[reacting-to-other-plugins-java]]
|
||||||
=== Reacting to the `java` Plugin
|
=== Reacting to the Java Plugin
|
||||||
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot plugin:
|
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot plugin:
|
||||||
|
|
||||||
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
|
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
|
||||||
|
@ -32,7 +32,7 @@ When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring
|
||||||
|
|
||||||
|
|
||||||
[[reacting-to-other-plugins-war]]
|
[[reacting-to-other-plugins-war]]
|
||||||
=== Reacting to the `war` Plugin
|
=== Reacting to the War Plugin
|
||||||
When Gradle's {war-plugin}[`war` plugin] is applied to a project, the Spring Boot plugin:
|
When Gradle's {war-plugin}[`war` plugin] is applied to a project, the Spring Boot plugin:
|
||||||
|
|
||||||
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an executable, fat war for the project.
|
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an executable, fat war for the project.
|
||||||
|
@ -50,7 +50,7 @@ When the {dependency-management-plugin}[`io.spring.dependency-management` plugin
|
||||||
|
|
||||||
|
|
||||||
[[reacting-to-other-plugins-application]]
|
[[reacting-to-other-plugins-application]]
|
||||||
=== Reacting to the `application` Plugin
|
=== Reacting to the Application Plugin
|
||||||
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the Spring Boot plugin:
|
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the Spring Boot plugin:
|
||||||
|
|
||||||
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
|
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
|
||||||
|
@ -64,5 +64,5 @@ When Gradle's {application-plugin}[`application` plugin] is applied to a project
|
||||||
|
|
||||||
|
|
||||||
[[reacting-to-other-plugins-maven]]
|
[[reacting-to-other-plugins-maven]]
|
||||||
=== Reacting to the `maven` plugin
|
=== Reacting to the Maven plugin
|
||||||
When Gradle's {maven-plugin}[`maven` plugin] is applied to a project, the Spring Boot plugin will configure the `uploadBootArchives` `Upload` task to ensure that no dependencies are declared in the pom that it generates.
|
When Gradle's {maven-plugin}[`maven` plugin] is applied to a project, the Spring Boot plugin will configure the `uploadBootArchives` `Upload` task to ensure that no dependencies are declared in the pom that it generates.
|
||||||
|
|
Loading…
Reference in New Issue