mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-09-03 04:26:12 +08:00
Use one sentence per line in Actuator and Gradle plugin doc source
Closes gh-18185
This commit is contained in:
parent
795c2f225f
commit
7b1e10ed00
@ -8,14 +8,12 @@ The `auditevents` endpoint provides information about the application's audit ev
|
||||
[[audit-events-retrieving]]
|
||||
== Retrieving Audit Events
|
||||
|
||||
To retrieve the audit events, make a `GET` request to `/actuator/auditevents`, as shown
|
||||
in the following curl-based example:
|
||||
To retrieve the audit events, make a `GET` request to `/actuator/auditevents`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}auditevents/filtered/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves `logout` events for the principal, `alice`, that occurred
|
||||
after 09:37 on 7 November 2017 in the UTC timezone. The resulting response is similar to
|
||||
the following:
|
||||
The preceding example retrieves `logout` events for the principal, `alice`, that occurred after 09:37 on 7 November 2017 in the UTC timezone.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}auditevents/filtered/http-response.adoc[]
|
||||
|
||||
@ -24,8 +22,8 @@ include::{snippets}auditevents/filtered/http-response.adoc[]
|
||||
[[audit-events-retrieving-query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
The endpoint uses query parameters to limit the events that it returns. The following
|
||||
table shows the supported query parameters:
|
||||
The endpoint uses query parameters to limit the events that it returns.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}auditevents/filtered/request-parameters.adoc[]
|
||||
@ -35,8 +33,8 @@ include::{snippets}auditevents/filtered/request-parameters.adoc[]
|
||||
[[audit-events-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of all of the audit events that matched the query. The
|
||||
following table describes the structure of the response:
|
||||
The response contains details of all of the audit events that matched the query.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}auditevents/all/response-fields.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `beans` endpoint provides information about the application's beans.
|
||||
[[beans-retrieving]]
|
||||
== Retrieving the Beans
|
||||
|
||||
To retrieve the beans, make a `GET` request to `/actuator/beans`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the beans, make a `GET` request to `/actuator/beans`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}beans/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}beans/http-response.adoc[]
|
||||
[[beans-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's beans. The following table describes
|
||||
the structure of the response:
|
||||
The response contains details of the application's beans.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}beans/response-fields.adoc[]
|
||||
|
@ -7,8 +7,7 @@ The `caches` endpoint provides access to the application's caches.
|
||||
|
||||
[[caches-all]]
|
||||
== Retrieving All Caches
|
||||
To retrieve the application's caches, make a `GET` request to `/actuator/caches`, as
|
||||
shown in the following curl-based example:
|
||||
To retrieve the application's caches, make a `GET` request to `/actuator/caches`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}caches/all/curl-request.adoc[]
|
||||
|
||||
@ -20,8 +19,8 @@ include::{snippets}caches/all/http-response.adoc[]
|
||||
|
||||
[[caches-all-response-structure]]
|
||||
=== Response Structure
|
||||
The response contains details of the application's caches. The following table describes
|
||||
the structure of the response:
|
||||
The response contains details of the application's caches.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}caches/all/response-fields.adoc[]
|
||||
@ -30,13 +29,12 @@ include::{snippets}caches/all/response-fields.adoc[]
|
||||
|
||||
[[caches-named]]
|
||||
== Retrieving Caches by Name
|
||||
To retrieve a cache by name, make a `GET` request to `/actuator/caches/\{name}`,
|
||||
as shown in the following curl-based example:
|
||||
To retrieve a cache by name, make a `GET` request to `/actuator/caches/\{name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}caches/named/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the cache named `cities`. The
|
||||
resulting response is similar to the following:
|
||||
The preceding example retrieves information about the cache named `cities`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}caches/named/http-response.adoc[]
|
||||
|
||||
@ -44,9 +42,9 @@ include::{snippets}caches/named/http-response.adoc[]
|
||||
|
||||
[[caches-named-query-parameters]]
|
||||
=== Query Parameters
|
||||
If the requested name is specific enough to identify a single cache, no extra parameter is
|
||||
required. Otherwise, the `cacheManager` must be specified. The following table shows the
|
||||
supported query parameters:
|
||||
If the requested name is specific enough to identify a single cache, no extra parameter is required.
|
||||
Otherwise, the `cacheManager` must be specified.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}caches/named/request-parameters.adoc[]
|
||||
@ -55,8 +53,8 @@ include::{snippets}caches/named/request-parameters.adoc[]
|
||||
|
||||
[[caches-named-response-structure]]
|
||||
=== Response Structure
|
||||
The response contains details of the requested cache. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the requested cache.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}caches/named/response-fields.adoc[]
|
||||
@ -65,8 +63,7 @@ include::{snippets}caches/named/response-fields.adoc[]
|
||||
|
||||
[[caches-evict-all]]
|
||||
== Evict All Caches
|
||||
To clear all available caches, make a `DELETE` request to `/actuator/caches` as shown in
|
||||
the following curl-based example:
|
||||
To clear all available caches, make a `DELETE` request to `/actuator/caches` as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}caches/evict-all/curl-request.adoc[]
|
||||
|
||||
@ -74,21 +71,19 @@ include::{snippets}caches/evict-all/curl-request.adoc[]
|
||||
|
||||
[[caches-evict-named]]
|
||||
== Evict a Cache by Name
|
||||
To evict a particular cache, make a `DELETE` request to `/actuator/caches/\{name}` as shown
|
||||
in the following curl-based example:
|
||||
To evict a particular cache, make a `DELETE` request to `/actuator/caches/\{name}` as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}caches/evict-named/curl-request.adoc[]
|
||||
|
||||
NOTE: As there are two caches named `countries`, the `cacheManager` has to be provided to
|
||||
specify which `Cache` should be cleared.
|
||||
NOTE: As there are two caches named `countries`, the `cacheManager` has to be provided to specify which `Cache` should be cleared.
|
||||
|
||||
|
||||
|
||||
[[caches-evict-named-request-structure]]
|
||||
=== Request Structure
|
||||
If the requested name is specific enough to identify a single cache, no extra parameter is
|
||||
required. Otherwise, the `cacheManager` must be specified. The following table shows the
|
||||
supported query parameters:
|
||||
If the requested name is specific enough to identify a single cache, no extra parameter is required.
|
||||
Otherwise, the `cacheManager` must be specified.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}caches/evict-named/request-parameters.adoc[]
|
||||
|
@ -1,16 +1,14 @@
|
||||
[[conditions]]
|
||||
= Conditions Evaluation Report (`conditions`)
|
||||
|
||||
The `conditions` endpoint provides information about the evaluation of conditions on
|
||||
configuration and auto-configuration classes.
|
||||
The `conditions` endpoint provides information about the evaluation of conditions on configuration and auto-configuration classes.
|
||||
|
||||
|
||||
|
||||
[[conditions-retrieving]]
|
||||
== Retrieving the Report
|
||||
|
||||
To retrieve the report, make a `GET` request to `/actuator/conditions`, as shown in
|
||||
the following curl-based example:
|
||||
To retrieve the report, make a `GET` request to `/actuator/conditions`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}conditions/curl-request.adoc[]
|
||||
|
||||
@ -23,8 +21,8 @@ include::{snippets}conditions/http-response.adoc[]
|
||||
[[conditions-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's condition evaluation. The following
|
||||
table describes the structure of the response:
|
||||
The response contains details of the application's condition evaluation.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}conditions/response-fields.adoc[]
|
||||
|
@ -1,16 +1,14 @@
|
||||
[[configprops]]
|
||||
= Configuration Properties (`configprops`)
|
||||
|
||||
The `configprops` endpoint provides information about the application's
|
||||
`@ConfigurationProperties` beans.
|
||||
The `configprops` endpoint provides information about the application's `@ConfigurationProperties` beans.
|
||||
|
||||
|
||||
|
||||
[[configprops-retrieving]]
|
||||
== 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:
|
||||
|
||||
include::{snippets}configprops/curl-request.adoc[]
|
||||
|
||||
@ -23,8 +21,8 @@ include::{snippets}configprops/http-response.adoc[]
|
||||
[[configprops-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's `@ConfigurationProperties` beans. The
|
||||
following table describes the structure of the response:
|
||||
The response contains details of the application's `@ConfigurationProperties` beans.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}configprops/response-fields.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `env` endpoint provides information about the application's `Environment`.
|
||||
[[env-entire]]
|
||||
== Retrieving the Entire Environment
|
||||
|
||||
To retrieve the entire environment, make a `GET` request to `/actuator/env`, as shown in
|
||||
the following curl-based example:
|
||||
To retrieve the entire environment, make a `GET` request to `/actuator/env`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}env/all/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}env/all/http-response.adoc[]
|
||||
[[env-entire-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's `Environment`. The following table
|
||||
describes the structure of the response:
|
||||
The response contains details of the application's `Environment`.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}env/all/response-fields.adoc[]
|
||||
@ -33,13 +32,12 @@ include::{snippets}env/all/response-fields.adoc[]
|
||||
[[env-single-property]]
|
||||
== Retrieving a Single Property
|
||||
|
||||
To retrieve a single property, make a `GET` request to `/actuator/env/{property.name}`,
|
||||
as shown in the following curl-based example:
|
||||
To retrieve a single property, make a `GET` request to `/actuator/env/{property.name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}env/single/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the property named
|
||||
`com.example.cache.max-size`. The resulting response is similar to the following:
|
||||
The preceding example retrieves information about the property named `com.example.cache.max-size`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}env/single/http-response.adoc[]
|
||||
|
||||
@ -48,8 +46,8 @@ include::{snippets}env/single/http-response.adoc[]
|
||||
[[env-single-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested property. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the requested property.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}env/single/response-fields.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `flyway` endpoint provides information about database migrations performed b
|
||||
[[flyway-retrieving]]
|
||||
== Retrieving the Migrations
|
||||
|
||||
To retrieve the migrations, make a `GET` request to `/actuator/flyway`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the migrations, make a `GET` request to `/actuator/flyway`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}flyway/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}flyway/http-response.adoc[]
|
||||
[[flyway-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's Flyway migrations. The following table
|
||||
describes the structure of the response:
|
||||
The response contains details of the application's Flyway migrations.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}flyway/response-fields.adoc[]
|
||||
|
@ -6,8 +6,7 @@ The `health` endpoint provides detailed information about the health of the appl
|
||||
|
||||
[[health-retrieving]]
|
||||
== Retrieving the Health of the application
|
||||
To retrieve the health of the application, make a `GET` request to `/actuator/health`,
|
||||
as shown in the following curl-based example:
|
||||
To retrieve the health of the application, make a `GET` request to `/actuator/health`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}health/curl-request.adoc[]
|
||||
|
||||
@ -19,8 +18,8 @@ include::{snippets}health/http-response.adoc[]
|
||||
|
||||
[[health-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
The response contains details of the health of the application. The following table
|
||||
describes the structure of the response:
|
||||
The response contains details of the health of the application.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}health/response-fields.adoc[]
|
||||
@ -29,8 +28,7 @@ include::{snippets}health/response-fields.adoc[]
|
||||
|
||||
[[health-retrieving-component]]
|
||||
== Retrieving the Health of a component
|
||||
To retrieve the health of a particular component of the application, make a `GET` request
|
||||
to `/actuator/health/\{component}`, as shown in the following curl-based example:
|
||||
To retrieve the health of a particular component of the application, make a `GET` request to `/actuator/health/\{component}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}health/component/curl-request.adoc[]
|
||||
|
||||
@ -52,10 +50,7 @@ include::{snippets}health/component/response-fields.adoc[]
|
||||
|
||||
[[health-retrieving-component-instance]]
|
||||
== Retrieving the Health of a component instance
|
||||
If a particular component consists of multiple instances (as the `broker` indicator in
|
||||
the example above), the health of a particular instance of that component can be retrieved
|
||||
by issuing a `GET` request to `/actuator/health/\{component}/\{instance}`, as shown in the
|
||||
following curl-based example:
|
||||
If a particular component consists of multiple instances (as the `broker` indicator in the example above), the health of a particular instance of that component can be retrieved by issuing a `GET` request to `/actuator/health/\{component}/\{instance}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}health/instance/curl-request.adoc[]
|
||||
|
||||
@ -67,8 +62,8 @@ include::{snippets}health/instance/http-response.adoc[]
|
||||
|
||||
[[health-retrieving-component-instance-response-structure]]
|
||||
=== Response Structure
|
||||
The response contains details of the health of an instance of a particular component of
|
||||
the application. The following table describes the structure of the response:
|
||||
The response contains details of the health of an instance of a particular component of the application.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}health/instance/response-fields.adoc[]
|
||||
|
@ -8,13 +8,11 @@ The `heapdump` endpoint provides a heap dump from the application's JVM.
|
||||
[[heapdump-retrieving]]
|
||||
== Retrieving the Heap Dump
|
||||
|
||||
To retrieve the heap dump, make a `GET` request to `/actuator/heapdump`. The response
|
||||
is binary data in https://docs.oracle.com/javase/8/docs/technotes/samples/hprof.html[
|
||||
HPROF] format and can be large. Typically, you should save the response to disk for
|
||||
subsequent analysis. When using curl, this can be achieved by using the `-O` option,
|
||||
as shown in the following example:
|
||||
To retrieve the heap dump, make a `GET` request to `/actuator/heapdump`.
|
||||
The response is binary data in https://docs.oracle.com/javase/8/docs/technotes/samples/hprof.html[HPROF] format and can be large.
|
||||
Typically, you should save the response to disk for subsequent analysis.
|
||||
When using curl, this can be achieved by using the `-O` option, as shown in the following example:
|
||||
|
||||
include::{snippets}heapdump/curl-request.adoc[]
|
||||
|
||||
The preceding example results in a file named `heapdump` being written to the current
|
||||
working directory.
|
||||
The preceding example results in a file named `heapdump` being written to the current working directory.
|
||||
|
@ -8,8 +8,7 @@ The `httptrace` endpoint provides information about HTTP request-response exchan
|
||||
[[http-trace-retrieving]]
|
||||
== Retrieving the Traces
|
||||
|
||||
To retrieve the traces, make a `GET` request to `/actuator/httptrace`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the traces, make a `GET` request to `/actuator/httptrace`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}httptrace/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}httptrace/http-response.adoc[]
|
||||
[[http-trace-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the traced HTTP request-response exchanges. The
|
||||
following table describes the structure of the response:
|
||||
The response contains details of the traced HTTP request-response exchanges.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}httptrace/response-fields.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `info` endpoint provides general information about the application.
|
||||
[[info-retrieving]]
|
||||
== Retrieving the Info
|
||||
|
||||
To retrieve the information about the application, make a `GET` request to
|
||||
`/actuator/info`, as shown in the following curl-based example:
|
||||
To retrieve the information about the application, make a `GET` request to `/actuator/info`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}info/curl-request.adoc[]
|
||||
|
||||
@ -22,9 +21,9 @@ include::{snippets}info/http-response.adoc[]
|
||||
[[info-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains general information about the application. Each section of the
|
||||
response is contributed by an `InfoContributor`. Spring Boot provides `build` and `git`
|
||||
contributions.
|
||||
The response contains general information about the application.
|
||||
Each section of the response is contributed by an `InfoContributor`.
|
||||
Spring Boot provides `build` and `git` contributions.
|
||||
|
||||
|
||||
|
||||
|
@ -1,15 +1,13 @@
|
||||
[[integrationgraph]]
|
||||
= Spring Integration graph (`integrationgraph`)
|
||||
|
||||
The `integrationgraph` endpoint exposes a graph containing all Spring Integration
|
||||
components.
|
||||
The `integrationgraph` endpoint exposes a graph containing all Spring Integration components.
|
||||
|
||||
|
||||
|
||||
[[integrationgraph-retrieving]]
|
||||
== Retrieving the Spring Integration graph
|
||||
To retrieve the information about the application, make a `GET` request to
|
||||
`/actuator/integrationgraph`, as shown in the following curl-based example:
|
||||
To retrieve the information about the application, make a `GET` request to `/actuator/integrationgraph`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}integrationgraph/graph/curl-request.adoc[]
|
||||
|
||||
@ -21,17 +19,14 @@ include::{snippets}integrationgraph/graph/http-response.adoc[]
|
||||
|
||||
[[integrationgraph-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
The response contains all Spring Integration components used within the application, as
|
||||
well as the links between them. More information about the structure can be found in the
|
||||
https://docs.spring.io/spring-integration/reference/html/#integration-graph[reference
|
||||
documentation].
|
||||
The response contains all Spring Integration components used within the application, as well as the links between them.
|
||||
More information about the structure can be found in the https://docs.spring.io/spring-integration/reference/html/#integration-graph[reference documentation].
|
||||
|
||||
|
||||
|
||||
[[integrationgraph-rebuilding]]
|
||||
== Rebuilding the Spring Integration graph
|
||||
To rebuild the exposed graph, make a `POST` request to `/actuator/integrationgraph`, as
|
||||
shown in the following curl-based example:
|
||||
To rebuild the exposed graph, make a `POST` request to `/actuator/integrationgraph`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}integrationgraph/rebuild/curl-request.adoc[]
|
||||
|
||||
|
@ -1,16 +1,14 @@
|
||||
[[liquibase]]
|
||||
= Liquibase (`liquibase`)
|
||||
|
||||
The `liquibase` endpoint provides information about database change sets applied by
|
||||
Liquibase.
|
||||
The `liquibase` endpoint provides information about database change sets applied by Liquibase.
|
||||
|
||||
|
||||
|
||||
[[liquibase-retrieving]]
|
||||
== Retrieving the Changes
|
||||
|
||||
To retrieve the changes, make a `GET` request to `/actuator/liquibase`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the changes, make a `GET` request to `/actuator/liquibase`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}liquibase/curl-request.adoc[]
|
||||
|
||||
@ -23,8 +21,8 @@ include::{snippets}liquibase/http-response.adoc[]
|
||||
[[liquibase-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's Liquibase change sets. The following
|
||||
table describes the structure of the response:
|
||||
The response contains details of the application's Liquibase change sets.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}liquibase/response-fields.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `logfile` endpoint provides access to the contents of the application's log
|
||||
[[logfile-retrieving]]
|
||||
== Retrieving the Log File
|
||||
|
||||
To retrieve the log file, make a `GET` request to `/actuator/logfile`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the log file, make a `GET` request to `/actuator/logfile`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}logfile/entire/curl-request.adoc[]
|
||||
|
||||
@ -24,12 +23,11 @@ include::{snippets}logfile/entire/http-response.adoc[]
|
||||
|
||||
NOTE: Retrieving part of the log file is not supported when using Jersey.
|
||||
|
||||
To retrieve part of the log file, make a `GET` request to `/actuator/logfile` by using
|
||||
the `Range` header, as shown in the following curl-based example:
|
||||
To retrieve part of the log file, make a `GET` request to `/actuator/logfile` by using the `Range` header, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}logfile/range/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the first 1024 bytes of the log file. The resulting
|
||||
response is similar to the following:
|
||||
The preceding example retrieves the first 1024 bytes of the log file.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}logfile/range/http-response.adoc[]
|
||||
|
@ -1,16 +1,14 @@
|
||||
[[loggers]]
|
||||
= Loggers (`loggers`)
|
||||
|
||||
The `loggers` endpoint provides access to the application's loggers and the configuration
|
||||
of their levels.
|
||||
The `loggers` endpoint provides access to the application's loggers and the configuration of their levels.
|
||||
|
||||
|
||||
|
||||
[[loggers-all]]
|
||||
== Retrieving All Loggers
|
||||
|
||||
To retrieve the application's loggers, make a `GET` request to `/actuator/loggers`, as
|
||||
shown in the following curl-based example:
|
||||
To retrieve the application's loggers, make a `GET` request to `/actuator/loggers`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}loggers/all/curl-request.adoc[]
|
||||
|
||||
@ -23,8 +21,8 @@ include::{snippets}loggers/all/http-response.adoc[]
|
||||
[[loggers-all-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's loggers. The following table describes
|
||||
the structure of the response:
|
||||
The response contains details of the application's loggers.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}loggers/all/response-fields.adoc[]
|
||||
@ -34,13 +32,12 @@ include::{snippets}loggers/all/response-fields.adoc[]
|
||||
[[loggers-single]]
|
||||
== Retrieving a Single Logger
|
||||
|
||||
To retrieve a single logger, make a `GET` request to `/actuator/loggers/{logger.name}`,
|
||||
as shown in the following curl-based example:
|
||||
To retrieve a single logger, make a `GET` request to `/actuator/loggers/{logger.name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}loggers/single/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the logger named `com.example`. The
|
||||
resulting response is similar to the following:
|
||||
The preceding example retrieves information about the logger named `com.example`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}loggers/single/http-response.adoc[]
|
||||
|
||||
@ -49,8 +46,8 @@ include::{snippets}loggers/single/http-response.adoc[]
|
||||
[[loggers-single-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested logger. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the requested logger.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}loggers/single/response-fields.adoc[]
|
||||
@ -60,9 +57,7 @@ include::{snippets}loggers/single/response-fields.adoc[]
|
||||
[[loggers-setting-level]]
|
||||
== Setting a Log Level
|
||||
|
||||
To set the level of a logger, make a `POST` request to
|
||||
`/actuator/loggers/{logger.name}` with a JSON body that specifies the configured level
|
||||
for the logger, as shown in the following curl-based example:
|
||||
To set the level of a logger, make a `POST` request to `/actuator/loggers/{logger.name}` with a JSON body that specifies the configured level for the logger, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}loggers/set/curl-request.adoc[]
|
||||
|
||||
@ -73,8 +68,8 @@ The preceding example sets the `configuredLevel` of the `com.example` logger to
|
||||
[[loggers-setting-level-request-structure]]
|
||||
=== Request Structure
|
||||
|
||||
The request specifies the desired level of the logger. The following table describes the
|
||||
structure of the request:
|
||||
The request specifies the desired level of the logger.
|
||||
The following table describes the structure of the request:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}loggers/set/request-fields.adoc[]
|
||||
@ -84,9 +79,7 @@ include::{snippets}loggers/set/request-fields.adoc[]
|
||||
[[loggers-clearing-level]]
|
||||
== Clearing a Log Level
|
||||
|
||||
To clear the level of a logger, make a `POST` request to
|
||||
`/actuator/loggers/{logger.name}` with a JSON body containing an empty object, as shown
|
||||
in the following curl-based example:
|
||||
To clear the level of a logger, make a `POST` request to `/actuator/loggers/{logger.name}` with a JSON body containing an empty object, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}loggers/clear/curl-request.adoc[]
|
||||
|
||||
|
@ -8,8 +8,7 @@ The `mappings` endpoint provides information about the application's request map
|
||||
[[mappings-retrieving]]
|
||||
== Retrieving the Mappings
|
||||
|
||||
To retrieve the mappings, make a `GET` request to `/actuator/mappings`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the mappings, make a `GET` request to `/actuator/mappings`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}mappings/curl-request.adoc[]
|
||||
|
||||
@ -22,23 +21,21 @@ include::{snippets}mappings/http-response.adoc[]
|
||||
[[mappings-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's mappings. The items found in the
|
||||
response depend on the type of web application (reactive or Servlet-based). The
|
||||
following table describes the structure of the common elements of the response:
|
||||
The response contains details of the application's mappings.
|
||||
The items found in the response depend on the type of web application (reactive or Servlet-based).
|
||||
The following table describes the structure of the common elements of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}mappings/response-fields.adoc[]
|
||||
|
||||
The entries that may be found in `contexts.*.mappings` are described in the
|
||||
following sections.
|
||||
The entries that may be found in `contexts.*.mappings` are described in the following sections.
|
||||
|
||||
|
||||
[[mappings-retrieving-response-structure-dispatcher-servlets]]
|
||||
=== Dispatcher Servlets Response Structure
|
||||
|
||||
When using Spring MVC, the response contains details of any `DispatcherServlet`
|
||||
request mappings beneath `contexts.*.mappings.dispatcherServlets`. The following
|
||||
table describes the structure of this section of the response:
|
||||
When using Spring MVC, the response contains details of any `DispatcherServlet` request mappings beneath `contexts.*.mappings.dispatcherServlets`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="4,1,2"]
|
||||
include::{snippets}mappings/response-fields-dispatcher-servlets.adoc[]
|
||||
@ -48,9 +45,8 @@ include::{snippets}mappings/response-fields-dispatcher-servlets.adoc[]
|
||||
[[mappings-retrieving-response-structure-servlets]]
|
||||
=== Servlets Response Structure
|
||||
|
||||
When using the Servlet stack, the response contains details of any `Servlet` mappings
|
||||
beneath `contexts.*.mappings.servlets`. The following table describes the structure of
|
||||
this section of the response:
|
||||
When using the Servlet stack, the response contains details of any `Servlet` mappings beneath `contexts.*.mappings.servlets`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}mappings/response-fields-servlets.adoc[]
|
||||
@ -60,9 +56,8 @@ include::{snippets}mappings/response-fields-servlets.adoc[]
|
||||
[[mappings-retrieving-response-structure-servlet-filters]]
|
||||
=== Servlet Filters Response Structure
|
||||
|
||||
When using the Servlet stack, the response contains details of any `Filter` mappings
|
||||
beneath `contexts.*.mappings.servletFilters`. The following table describes the
|
||||
structure of this section of the response:
|
||||
When using the Servlet stack, the response contains details of any `Filter` mappings beneath `contexts.*.mappings.servletFilters`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}mappings/response-fields-servlet-filters.adoc[]
|
||||
@ -72,9 +67,8 @@ include::{snippets}mappings/response-fields-servlet-filters.adoc[]
|
||||
[[mappings-retrieving-response-structure-dispatcher-handlers]]
|
||||
=== Dispatcher Handlers Response Structure
|
||||
|
||||
When using Spring WebFlux, the response contains details of any `DispatcherHandler`
|
||||
request mappings beneath `contexts.*.mappings.dispatcherHandlers`. The following
|
||||
table describes the structure of this section of the response:
|
||||
When using Spring WebFlux, the response contains details of any `DispatcherHandler` request mappings beneath `contexts.*.mappings.dispatcherHandlers`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="4,1,2"]
|
||||
include::{snippets}mappings/response-fields-dispatcher-handlers.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `metrics` endpoint provides access to application metrics.
|
||||
[[metrics-retrieving-names]]
|
||||
== Retrieving Metric Names
|
||||
|
||||
To retrieve the names of the available metrics, make a `GET` request to
|
||||
`/actuator/metrics`, as shown in the following curl-based example:
|
||||
To retrieve the names of the available metrics, make a `GET` request to `/actuator/metrics`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}metrics/names/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}metrics/names/http-response.adoc[]
|
||||
[[metrics-retrieving-names-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the metric names. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the metric names.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,2"]
|
||||
include::{snippets}metrics/names/response-fields.adoc[]
|
||||
@ -33,13 +32,12 @@ include::{snippets}metrics/names/response-fields.adoc[]
|
||||
[[metrics-retrieving-metric]]
|
||||
== Retrieving a Metric
|
||||
|
||||
To retrieve a metric, make a `GET` request to `/actuator/metrics/{metric.name}`, as
|
||||
shown in the following curl-based example:
|
||||
To retrieve a metric, make a `GET` request to `/actuator/metrics/{metric.name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}metrics/metric/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the metric named `jvm.memory.max`. The
|
||||
resulting response is similar to the following:
|
||||
The preceding example retrieves information about the metric named `jvm.memory.max`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}metrics/metric/http-response.adoc[]
|
||||
|
||||
@ -48,8 +46,8 @@ include::{snippets}metrics/metric/http-response.adoc[]
|
||||
[[metrics-retrieving-metric-query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
The endpoint uses query parameters to <<metrics-drilling-down,drill down>> into a metric
|
||||
by using its tags. The following table shows the single supported query parameter:
|
||||
The endpoint uses query parameters to <<metrics-drilling-down,drill down>> into a metric by using its tags.
|
||||
The following table shows the single supported query parameter:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}metrics/metric-with-tags/request-parameters.adoc[]
|
||||
@ -59,8 +57,8 @@ include::{snippets}metrics/metric-with-tags/request-parameters.adoc[]
|
||||
[[metrics-retrieving-metric-response-structure]]
|
||||
=== Response structure
|
||||
|
||||
The response contains details of the metric. The following table describes the structure
|
||||
of the response:
|
||||
The response contains details of the metric.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
include::{snippets}metrics/metric/response-fields.adoc[]
|
||||
|
||||
@ -68,13 +66,11 @@ include::{snippets}metrics/metric/response-fields.adoc[]
|
||||
[[metrics-drilling-down]]
|
||||
== Drilling Down
|
||||
|
||||
To drill down into a metric, make a `GET` request to `/actuator/metrics/{metric.name}`
|
||||
using the `tag` query parameter, as shown in the following curl-based example:
|
||||
To drill down into a metric, make a `GET` request to `/actuator/metrics/{metric.name}` using the `tag` query parameter, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}metrics/metric-with-tags/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the `jvm.memory.max` metric, where the `area` tag has a
|
||||
value of `nonheap` and the `id` attribute has a value of `Compressed Class Space`. The
|
||||
resulting response is similar to the following:
|
||||
The preceding example retrieves the `jvm.memory.max` metric, where the `area` tag has a value of `nonheap` and the `id` attribute has a value of `Compressed Class Space`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}metrics/metric-with-tags/http-response.adoc[]
|
||||
|
@ -1,16 +1,14 @@
|
||||
[[prometheus]]
|
||||
= Prometheus (`prometheus`)
|
||||
|
||||
The `prometheus` endpoint provides Spring Boot application's metrics in the format
|
||||
required for scraping by a Prometheus server.
|
||||
The `prometheus` endpoint provides Spring Boot application's metrics in the format required for scraping by a Prometheus server.
|
||||
|
||||
|
||||
|
||||
[[prometheus-retrieving]]
|
||||
== Retrieving the Metrics
|
||||
|
||||
To retrieve the metrics, make a `GET` request to `/actuator/prometheus`, as shown in
|
||||
the following curl-based example:
|
||||
To retrieve the metrics, make a `GET` request to `/actuator/prometheus`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}prometheus/curl-request.adoc[]
|
||||
|
||||
|
@ -1,16 +1,14 @@
|
||||
[[scheduled-tasks]]
|
||||
= Scheduled Tasks (`scheduledtasks`)
|
||||
|
||||
The `scheduledtasks` endpoint provides information about the application's scheduled
|
||||
tasks.
|
||||
The `scheduledtasks` endpoint provides information about the application's scheduled tasks.
|
||||
|
||||
|
||||
|
||||
[[scheduled-tasks-retrieving]]
|
||||
== Retrieving the Scheduled Tasks
|
||||
|
||||
To retrieve the scheduled tasks, make a `GET` request to `/actuator/scheduledtasks`,
|
||||
as shown in the following curl-based example:
|
||||
To retrieve the scheduled tasks, make a `GET` request to `/actuator/scheduledtasks`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}scheduled-tasks/curl-request.adoc[]
|
||||
|
||||
@ -23,8 +21,8 @@ include::{snippets}scheduled-tasks/http-response.adoc[]
|
||||
[[scheduled-tasks-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's scheduled tasks. The following table
|
||||
describes the structure of the response:
|
||||
The response contains details of the application's scheduled tasks.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}scheduled-tasks/response-fields.adoc[]
|
||||
|
@ -1,22 +1,18 @@
|
||||
[[sessions]]
|
||||
= Sessions (`sessions`)
|
||||
|
||||
The `sessions` endpoint provides information about the application's HTTP sessions that
|
||||
are managed by Spring Session.
|
||||
The `sessions` endpoint provides information about the application's HTTP sessions that are managed by Spring Session.
|
||||
|
||||
|
||||
|
||||
[[sessions-retrieving]]
|
||||
== Retrieving Sessions
|
||||
|
||||
To retrieve the sessions, make a `GET` request to `/actuator/sessions`, as shown in the
|
||||
following curl-based example:
|
||||
To retrieve the sessions, make a `GET` request to `/actuator/sessions`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}sessions/username/curl-request.adoc[]
|
||||
|
||||
The preceding examples retrieves all of the sessions for the user whose username is
|
||||
`alice`.
|
||||
|
||||
The preceding examples retrieves all of the sessions for the user whose username is `alice`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}sessions/username/http-response.adoc[]
|
||||
@ -26,8 +22,8 @@ include::{snippets}sessions/username/http-response.adoc[]
|
||||
[[sessions-retrieving-query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
The endpoint uses query parameters to limit the sessions that it returns. The following
|
||||
table shows the single required query parameter:
|
||||
The endpoint uses query parameters to limit the sessions that it returns.
|
||||
The following table shows the single required query parameter:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}sessions/username/request-parameters.adoc[]
|
||||
@ -37,8 +33,8 @@ include::{snippets}sessions/username/request-parameters.adoc[]
|
||||
[[sessions-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the matching sessions. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the matching sessions.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}sessions/username/response-fields.adoc[]
|
||||
@ -48,14 +44,12 @@ include::{snippets}sessions/username/response-fields.adoc[]
|
||||
[[sessions-retrieving-id]]
|
||||
== Retrieving a Single Session
|
||||
|
||||
To retrieve a single session, make a `GET` request to `/actuator/sessions/\{id}`, as
|
||||
shown in the following curl-based example:
|
||||
To retrieve a single session, make a `GET` request to `/actuator/sessions/\{id}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}sessions/id/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the session with the `id` of
|
||||
`4db5efcc-99cb-4d05-a52c-b49acfbb7ea9`. The resulting response is similar to the
|
||||
following:
|
||||
The preceding example retrieves the session with the `id` of `4db5efcc-99cb-4d05-a52c-b49acfbb7ea9`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}sessions/id/http-response.adoc[]
|
||||
|
||||
@ -64,8 +58,8 @@ include::{snippets}sessions/id/http-response.adoc[]
|
||||
[[sessions-retrieving-id-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested session. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the requested session.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}sessions/id/response-fields.adoc[]
|
||||
@ -75,10 +69,8 @@ include::{snippets}sessions/id/response-fields.adoc[]
|
||||
[[sessions-deleting]]
|
||||
== Deleting a Session
|
||||
|
||||
To delete a session, make a `DELETE` request to `/actuator/sessions/\{id}`, as shown in
|
||||
the following curl-based example:
|
||||
To delete a session, make a `DELETE` request to `/actuator/sessions/\{id}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}sessions/delete/curl-request.adoc[]
|
||||
|
||||
The preceding example deletes the session with the `id` of
|
||||
`4db5efcc-99cb-4d05-a52c-b49acfbb7ea9`.
|
||||
The preceding example deletes the session with the `id` of `4db5efcc-99cb-4d05-a52c-b49acfbb7ea9`.
|
||||
|
@ -8,8 +8,7 @@ The `shutdown` endpoint is used to shut down the application.
|
||||
[[shutdown-shutting-down]]
|
||||
== Shutting Down the Application
|
||||
|
||||
To shut down the application, make a `POST` request to `/actuator/shutdown`, as shown
|
||||
in the following curl-based example:
|
||||
To shut down the application, make a `POST` request to `/actuator/shutdown`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}shutdown/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}shutdown/http-response.adoc[]
|
||||
[[shutdown-shutting-down-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the result of the shutdown request. The following table
|
||||
describes the structure of the response:
|
||||
The response contains details of the result of the shutdown request.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}shutdown/response-fields.adoc[]
|
||||
|
@ -8,8 +8,7 @@ The `threaddump` endpoint provides a thread dump from the application's JVM.
|
||||
[[threaddump-retrieving]]
|
||||
== Retrieving the Thread Dump
|
||||
|
||||
To retrieve the thread dump, make a `GET` request to `/actuator/threaddump`, as shown
|
||||
in the following curl-based example:
|
||||
To retrieve the thread dump, make a `GET` request to `/actuator/threaddump`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}threaddump/curl-request.adoc[]
|
||||
|
||||
@ -22,8 +21,8 @@ include::{snippets}threaddump/http-response.adoc[]
|
||||
[[threaddump-retrieving-response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the JVM's threads. The following table describes the
|
||||
structure of the response:
|
||||
The response contains details of the JVM's threads.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,2"]
|
||||
include::{snippets}threaddump/response-fields.adoc[]
|
||||
|
@ -4,8 +4,7 @@
|
||||
To get started with the plugin it needs to be applied to your project.
|
||||
|
||||
ifeval::["{version-type}" == "RELEASE"]
|
||||
The plugin is https://plugins.gradle.org/plugin/org.springframework.boot[published to
|
||||
Gradle's plugin portal] and can be applied using the `plugins` block:
|
||||
The plugin is https://plugins.gradle.org/plugin/org.springframework.boot[published to Gradle's plugin portal] and can be applied using the `plugins` block:
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
----
|
||||
@ -19,18 +18,16 @@ include::../gradle/getting-started/apply-plugin-release.gradle.kts[]
|
||||
----
|
||||
endif::[]
|
||||
ifeval::["{version-type}" == "MILESTONE"]
|
||||
The plugin is published to the Spring milestones repository. For Gradle versions less
|
||||
than 4.10, this means that you must apply the plugin imperatively:
|
||||
The plugin is published to the Spring milestones repository.
|
||||
For Gradle versions less than 4.10, this means that you must apply the plugin imperatively:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes"]
|
||||
----
|
||||
include::../gradle/getting-started/apply-plugin-milestone.gradle[]
|
||||
----
|
||||
|
||||
For Gradle 4.10 and above, Gradle can be configured to use the milestones repository
|
||||
and it can be applied using the `plugins` block. To configure Gradle to use the milestones
|
||||
repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts`
|
||||
(Kotlin):
|
||||
For Gradle 4.10 and above, Gradle can be configured to use the milestones repository and it can be applied using the `plugins` block.
|
||||
To configure Gradle to use the milestones repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts` (Kotlin):
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -59,18 +56,16 @@ include::../gradle/getting-started/apply-plugin-release.gradle.kts[]
|
||||
----
|
||||
endif::[]
|
||||
ifeval::["{version-type}" == "SNAPSHOT"]
|
||||
The plugin is published to the Spring snapshots repository. For Gradle versions less
|
||||
than 4.10, this means that you must apply the plugin imperatively:
|
||||
The plugin is published to the Spring snapshots repository.
|
||||
For Gradle versions less than 4.10, this means that you must apply the plugin imperatively:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes"]
|
||||
----
|
||||
include::../gradle/getting-started/apply-plugin-milestone.gradle[]
|
||||
----
|
||||
|
||||
For Gradle 4.10 and above, Gradle can be configured to use the snapshots repository
|
||||
and it can be applied using the `plugins` block. To configure Gradle to use the snapshots
|
||||
repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts`
|
||||
(Kotlin):
|
||||
For Gradle 4.10 and above, Gradle can be configured to use the snapshots repository and it can be applied using the `plugins` block.
|
||||
To configure Gradle to use the snapshots repository, add the following to your `settings.gradle` (Groovy) or `settings.gradle.kts` (Kotlin):
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -99,15 +94,11 @@ include::../gradle/getting-started/apply-plugin-release.gradle.kts[]
|
||||
----
|
||||
endif::[]
|
||||
|
||||
Applied in isolation the plugin makes few changes to a project. Instead, the plugin
|
||||
detects when certain other plugins are applied and reacts accordingly. For example, when
|
||||
the `java` plugin is applied a task for building an executable jar is automatically
|
||||
configured.
|
||||
|
||||
A typical Spring Boot project will apply the {groovy-plugin}[`groovy`],
|
||||
{java-plugin}java_plugin.html[`java`], or {kotlin-plugin}[`org.jetbrains.kotlin.jvm`]
|
||||
plugin and the {dependency-management-plugin}[`io.spring.dependency-management`] plugin as
|
||||
a minimum. For example:
|
||||
Applied in isolation the plugin makes few changes to a project.
|
||||
Instead, the plugin detects when certain other plugins are applied and reacts accordingly.
|
||||
For example, when the `java` plugin is applied a task for building an executable jar is automatically configured.
|
||||
A typical Spring Boot project will apply the {groovy-plugin}[`groovy`], {java-plugin}java_plugin.html[`java`], or {kotlin-plugin}[`org.jetbrains.kotlin.jvm`] plugin and the {dependency-management-plugin}[`io.spring.dependency-management`] plugin as a minimum.
|
||||
For example:
|
||||
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
@ -122,5 +113,4 @@ include::../gradle/getting-started/typical-plugins.gradle[tags=apply]
|
||||
include::../gradle/getting-started/typical-plugins.gradle.kts[tags=apply]
|
||||
----
|
||||
|
||||
To learn more about how the Spring Boot plugin behaves when other plugins are applied
|
||||
please see the section on <<reacting-to-other-plugins, reacting to other plugins>>.
|
||||
To learn more about how the Spring Boot plugin behaves when other plugins are applied please see the section on <<reacting-to-other-plugins, reacting to other plugins>>.
|
||||
|
@ -34,11 +34,10 @@ Andy Wilkinson
|
||||
[[introduction]]
|
||||
== Introduction
|
||||
|
||||
The Spring Boot Gradle Plugin provides Spring Boot support in https://gradle.org[Gradle],
|
||||
allowing you to package executable jar or war archives, run Spring Boot applications, and
|
||||
use the dependency management provided by `spring-boot-dependencies`. Spring Boot's
|
||||
Gradle plugin requires Gradle 4.4 or later. If you choose to use the newer Kotlin DSL,
|
||||
it requires Gradle 4.10 or later.
|
||||
The Spring Boot Gradle Plugin provides Spring Boot support in https://gradle.org[Gradle].
|
||||
It allows you to package executable jar or war archives, run Spring Boot applications, and use the dependency management provided by `spring-boot-dependencies`.
|
||||
Spring Boot's Gradle plugin requires Gradle 4.4 or later.
|
||||
If you choose to use the newer Kotlin DSL, it requires Gradle 4.10 or later.
|
||||
|
||||
In addition to this user guide, {api-documentation}[API documentation] is also available.
|
||||
|
||||
|
@ -5,10 +5,9 @@
|
||||
[[integrating-with-actuator-build-info]]
|
||||
=== Generating build information
|
||||
|
||||
Spring Boot Actuator's `info` endpoint automatically publishes information about your
|
||||
build in the presence of a `META-INF/build-info.properties` file. A
|
||||
{build-info-javadoc}[`BuildInfo`] task is provided to generate this file. The easiest way
|
||||
to use the task is via the plugin's DSL:
|
||||
Spring Boot Actuator's `info` endpoint automatically publishes information about your build in the presence of a `META-INF/build-info.properties` file.
|
||||
A {build-info-javadoc}[`BuildInfo`] task is provided to generate this file.
|
||||
The easiest way to use the task is via the plugin's DSL:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -23,10 +22,8 @@ include::../gradle/integrating-with-actuator/build-info-basic.gradle.kts[tags=bu
|
||||
----
|
||||
|
||||
|
||||
This will configure a {build-info-javadoc}[`BuildInfo`] task named `bootBuildInfo` and, if
|
||||
it exists, make the Java plugin's `classes` task depend upon it. The task's destination
|
||||
directory will be `META-INF` in the output directory of the main source set's resources
|
||||
(typically `build/resources/main`).
|
||||
This will configure a {build-info-javadoc}[`BuildInfo`] task named `bootBuildInfo` and, if it exists, make the Java plugin's `classes` task depend upon it.
|
||||
The task's destination directory will be `META-INF` in the output directory of the main source set's resources (typically `build/resources/main`).
|
||||
|
||||
By default, the generated build information is derived from the project:
|
||||
|
||||
@ -66,12 +63,11 @@ include::../gradle/integrating-with-actuator/build-info-custom-values.gradle.kts
|
||||
----
|
||||
|
||||
|
||||
The default value for `build.time` is the instant at which the project is being built. A
|
||||
side-effect of this is that the task will never be up-to-date. As a result, builds will
|
||||
take longer as more tasks, including the project's tests, will have to be executed.
|
||||
Another side-effect is that the task's output will always change and, therefore, the build
|
||||
will not be truly repeatable. If you value build performance or repeatability more highly
|
||||
than the accuracy of the `build.time` property, set `time` to `null` or a fixed value.
|
||||
The default value for `build.time` is the instant at which the project is being built.
|
||||
A side-effect of this is that the task will never be up-to-date.
|
||||
As a result, builds will take longer as more tasks, including the project's tests, will have to be executed.
|
||||
Another side-effect is that the task's output will always change and, therefore, the build will not be truly repeatable.
|
||||
If you value build performance or repeatability more highly than the accuracy of the `build.time` property, set `time` to `null` or a fixed value.
|
||||
|
||||
Additional properties can also be added to the build information:
|
||||
|
||||
@ -86,4 +82,3 @@ include::../gradle/integrating-with-actuator/build-info-additional.gradle[tags=a
|
||||
----
|
||||
include::../gradle/integrating-with-actuator/build-info-additional.gradle.kts[tags=additional]
|
||||
----
|
||||
|
||||
|
@ -1,14 +1,10 @@
|
||||
[[managing-dependencies]]
|
||||
== Managing dependencies
|
||||
|
||||
When you apply the {dependency-management-plugin}[`io.spring.dependency-management`]
|
||||
plugin, Spring Boot's plugin will
|
||||
automatically <<reacting-to-other-plugins-dependency-management,import the
|
||||
`spring-boot-dependencies` bom>> from the version of Spring Boot that you are using.
|
||||
This provides a similar dependency management experience to the one that's enjoyed by
|
||||
Maven users. For example, it allows you to omit version numbers when declaring
|
||||
dependencies that are managed in the bom. To make use of this functionality, simply
|
||||
declare dependencies in the usual way but omit the version number:
|
||||
When you apply the {dependency-management-plugin}[`io.spring.dependency-management`] plugin, Spring Boot's plugin will automatically <<reacting-to-other-plugins-dependency-management,import the `spring-boot-dependencies` bom>> from the version of Spring Boot that you are using.
|
||||
This provides a similar dependency management experience to the one that's enjoyed by Maven users.
|
||||
For example, it allows you to omit version numbers when declaring dependencies that are managed in the bom.
|
||||
To make use of this functionality, simply declare dependencies in the usual way but omit the version number:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim",role="primary"]
|
||||
.Groovy
|
||||
@ -26,13 +22,11 @@ include::../gradle/managing-dependencies/dependencies.gradle.kts[tags=dependenci
|
||||
[[managing-dependencies-customizing]]
|
||||
=== Customizing managed versions
|
||||
|
||||
The `spring-boot-dependencies` bom that is automatically imported when the dependency
|
||||
management plugin is applied uses properties to control the versions of the dependencies
|
||||
that it manages. Please refer to the {github-code}/spring-boot-project/spring-boot-dependencies/pom.xml[bom]
|
||||
for a complete list of these properties.
|
||||
The `spring-boot-dependencies` bom that is automatically imported when the dependency management plugin is applied uses properties to control the versions of the dependencies that it manages.
|
||||
Please refer to the {github-code}/spring-boot-project/spring-boot-dependencies/pom.xml[bom] for a complete list of these properties.
|
||||
|
||||
To customize a managed version you set its corresponding property. For example, to
|
||||
customize the version of SLF4J which is controlled by the `slf4j.version` property:
|
||||
To customize a managed version you set its corresponding property.
|
||||
For example, to customize the version of SLF4J which is controlled by the `slf4j.version` property:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim",role="primary"]
|
||||
.Groovy
|
||||
@ -47,19 +41,16 @@ include::../gradle/managing-dependencies/custom-version.gradle.kts[tags=custom-v
|
||||
----
|
||||
|
||||
|
||||
WARNING: Each Spring Boot release is designed and tested against a specific set of
|
||||
third-party dependencies. Overriding versions may cause compatibility issues and should
|
||||
be done with care.
|
||||
WARNING: Each Spring Boot release is designed and tested against a specific set of third-party dependencies.
|
||||
Overriding versions may cause compatibility issues and should be done with care.
|
||||
|
||||
|
||||
|
||||
[[managing-dependencies-using-in-isolation]]
|
||||
=== Using Spring Boot's dependency management in isolation
|
||||
|
||||
Spring Boot's dependency management can be used in a project without applying Spring
|
||||
Boot's plugin to that project. The `SpringBootPlugin` class provides a `BOM_COORDINATES`
|
||||
constant that can be used to import the bom without having to know its group ID,
|
||||
artifact ID, or version.
|
||||
Spring Boot's dependency management can be used in a project without applying Spring Boot's plugin to that project.
|
||||
The `SpringBootPlugin` class provides a `BOM_COORDINATES` constant that can be used to import the bom without having to know its group ID, artifact ID, or version.
|
||||
|
||||
First, configure the project to depend on the Spring Boot plugin but do not apply it:
|
||||
|
||||
@ -101,10 +92,8 @@ include::../gradle/managing-dependencies/depend-on-plugin-release.gradle.kts[]
|
||||
----
|
||||
endif::[]
|
||||
|
||||
The Spring Boot plugin's dependency on the dependency management plugin means that you
|
||||
can use the dependency management plugin without having to declare a dependency on it.
|
||||
This also means that you will automatically use the same version of the dependency
|
||||
management plugin as Spring Boot uses.
|
||||
The Spring Boot plugin's dependency on the dependency management plugin means that you can use the dependency management plugin without having to declare a dependency on it.
|
||||
This also means that you will automatically use the same version of the dependency management plugin as Spring Boot uses.
|
||||
|
||||
Apply the dependency management plugin and then configure it to import Spring Boot's bom:
|
||||
|
||||
@ -121,12 +110,11 @@ include::../gradle/managing-dependencies/configure-bom.gradle.kts[tags=configure
|
||||
----
|
||||
|
||||
|
||||
The Kotlin code above is a bit awkward. That's because we're using the imperative way of
|
||||
applying the dependency management plugin.
|
||||
The Kotlin code above is a bit awkward.
|
||||
That's because we're using the imperative way of applying the dependency management plugin.
|
||||
|
||||
We can make the code less awkward by applying the plugin from the root parent project, or
|
||||
by using the `plugins` block as we're doing for the Spring Boot plugin. A downside of this
|
||||
method is that it forces us to specify the version of the dependency management plugin:
|
||||
We can make the code less awkward by applying the plugin from the root parent project, or by using the `plugins` block as we're doing for the Spring Boot plugin.
|
||||
A downside of this method is that it forces us to specify the version of the dependency management plugin:
|
||||
|
||||
[source,kotlin,indent=0,subs="verbatim,attributes"]
|
||||
----
|
||||
@ -137,5 +125,4 @@ include::../gradle/managing-dependencies/configure-bom-with-plugins.gradle.kts[t
|
||||
[[managing-dependencies-learning-more]]
|
||||
=== Learning more
|
||||
|
||||
To learn more about the capabilities of the dependency management plugin, please refer to
|
||||
its {dependency-management-plugin-documentation}[documentation].
|
||||
To learn more about the capabilities of the dependency management plugin, please refer to its {dependency-management-plugin-documentation}[documentation].
|
||||
|
@ -1,37 +1,33 @@
|
||||
[[packaging-executable]]
|
||||
== Packaging executable archives
|
||||
|
||||
The plugin can create executable archives (jar files and war files) that contain all of
|
||||
an application's dependencies and can then be run with `java -jar`.
|
||||
The plugin can create executable archives (jar files and war files) that contain all of an application's dependencies and can then be run with `java -jar`.
|
||||
|
||||
|
||||
|
||||
[[packaging-executable-jars]]
|
||||
=== Packaging executable jars
|
||||
|
||||
Executable jars can be built using the `bootJar` task. The task is automatically created
|
||||
when the `java` plugin is applied and is an instance of {boot-jar-javadoc}[`BootJar`].
|
||||
The `assemble` task is automatically configured to depend upon the `bootJar` task so
|
||||
running `assemble` (or `build`) will also run the `bootJar` task.
|
||||
Executable jars can be built using the `bootJar` task.
|
||||
The task is automatically created when the `java` plugin is applied and is an instance of {boot-jar-javadoc}[`BootJar`].
|
||||
The `assemble` task is automatically configured to depend upon the `bootJar` task so running `assemble` (or `build`) will also run the `bootJar` task.
|
||||
|
||||
|
||||
|
||||
[[packaging-executable-wars]]
|
||||
=== Packaging executable wars
|
||||
|
||||
Executable wars can be built using the `bootWar` task. The task is automatically created
|
||||
when the `war` plugin is applied and is an instance of {boot-war-javadoc}[`BootWar`].
|
||||
The `assemble` task is automatically configured to depend upon the `bootWar` task so
|
||||
running `assemble` (or `build`) will also run the `bootWar` task.
|
||||
Executable wars can be built using the `bootWar` task.
|
||||
The task is automatically created when the `war` plugin is applied and is an instance of {boot-war-javadoc}[`BootWar`].
|
||||
The `assemble` task is automatically configured to depend upon the `bootWar` task so running `assemble` (or `build`) will also run the `bootWar` task.
|
||||
|
||||
|
||||
|
||||
[[packaging-executable-wars-deployable]]
|
||||
==== Packaging executable and deployable wars
|
||||
|
||||
A war file can be packaged such that it can be executed using `java -jar` and deployed
|
||||
to an external container. To do so, the embedded servlet container dependencies should
|
||||
be added to the `providedRuntime` configuration, for example:
|
||||
A war file can be packaged such that it can be executed using `java -jar` and deployed to an external container.
|
||||
To do so, the embedded servlet container dependencies should be added to the `providedRuntime` configuration, for example:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -46,21 +42,17 @@ include::../gradle/packaging/war-container-dependency.gradle.kts[tags=dependenci
|
||||
----
|
||||
|
||||
|
||||
This ensures that they are package in the war file's `WEB-INF/lib-provided` directory
|
||||
from where they will not conflict with the external container's own classes.
|
||||
This ensures that they are package in the war file's `WEB-INF/lib-provided` directory from where they will not conflict with the external container's own classes.
|
||||
|
||||
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among
|
||||
other limitations, `compileOnly` dependencies are not on the test classpath so any
|
||||
web-based integration tests will fail.
|
||||
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among other limitations, `compileOnly` dependencies are not on the test classpath so any web-based integration tests will fail.
|
||||
|
||||
|
||||
|
||||
[[packaging-executable-and-normal]]
|
||||
=== Packaging executable and normal archives
|
||||
|
||||
By default, when the `bootJar` or `bootWar` tasks are configured, the `jar` or `war`
|
||||
tasks are disabled. A project can be configured to build both an executable archive
|
||||
and a normal archive at the same time by enabling the `jar` or `war` task:
|
||||
By default, when the `bootJar` or `bootWar` tasks are configured, the `jar` or `war` tasks are disabled.
|
||||
A project can be configured to build both an executable archive and a normal archive at the same time by enabling the `jar` or `war` task:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -75,9 +67,8 @@ include::../gradle/packaging/boot-jar-and-jar.gradle.kts[tags=enable-jar]
|
||||
----
|
||||
|
||||
|
||||
To avoid the executable archive and the normal archive from being written to the same
|
||||
location, one or the other should be configured to use a different location. One way to
|
||||
do so is by configuring a classifier:
|
||||
To avoid the executable archive and the normal archive from being written to the same location, one or the other should be configured to use a different location.
|
||||
One way to do so is by configuring a classifier:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -95,22 +86,17 @@ include::../gradle/packaging/boot-jar-and-jar.gradle.kts[tags=classifier]
|
||||
[[packaging-executable-configuring]]
|
||||
=== Configuring executable archive packaging
|
||||
|
||||
The {boot-jar-javadoc}[`BootJar`] and {boot-war-javadoc}[`BootWar`] tasks are subclasses
|
||||
of Gradle's `Jar` and `War` tasks respectively. As a result, all of the standard
|
||||
configuration options that are available when packaging a jar or war are also available
|
||||
when packaging an executable jar or war. A number of configuration options that are
|
||||
specific to executable jars and wars are also provided.
|
||||
The {boot-jar-javadoc}[`BootJar`] and {boot-war-javadoc}[`BootWar`] tasks are subclasses of Gradle's `Jar` and `War` tasks respectively.
|
||||
As a result, all of the standard configuration options that are available when packaging a jar or war are also available when packaging an executable jar or war.
|
||||
A number of configuration options that are specific to executable jars and wars are also provided.
|
||||
|
||||
|
||||
[[packaging-executable-configuring-main-class]]
|
||||
==== Configuring the main class
|
||||
|
||||
By default, the executable archive's main class will be configured automatically by
|
||||
looking for a class with a `public static void main(String[])` method in directories on
|
||||
the task's classpath.
|
||||
By default, the executable archive's main class will be configured automatically by looking for a class with a `public static void main(String[])` method in directories on the task's classpath.
|
||||
|
||||
The main class can also be configured explicitly using the task's `mainClassName`
|
||||
property:
|
||||
The main class can also be configured explicitly using the task's `mainClassName` property:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -125,8 +111,7 @@ include::../gradle/packaging/boot-jar-main-class.gradle.kts[tags=main-class]
|
||||
----
|
||||
|
||||
|
||||
Alternatively, the main class name can be configured project-wide using the
|
||||
`mainClassName` property of the Spring Boot DSL:
|
||||
Alternatively, the main class name can be configured project-wide using the `mainClassName` property of the Spring Boot DSL:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -141,8 +126,7 @@ include::../gradle/packaging/spring-boot-dsl-main-class.gradle.kts[tags=main-cla
|
||||
----
|
||||
|
||||
|
||||
If the {application-plugin}[`application` plugin] has been applied its `mainClassName`
|
||||
project property must be configured and can be used for the same purpose:
|
||||
If the {application-plugin}[`application` plugin] has been applied its `mainClassName` project property must be configured and can be used for the same purpose:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -174,10 +158,8 @@ include::../gradle/packaging/boot-jar-manifest-main-class.gradle.kts[tags=main-c
|
||||
[[packaging-executable-configuring-excluding-devtools]]
|
||||
==== Excluding Devtools
|
||||
|
||||
By default, Spring Boot's Devtools module,
|
||||
`org.springframework.boot:spring-boot-devtools`, will be excluded from an executable jar
|
||||
or war. If you want to include Devtools in your archive set the `excludeDevtools`
|
||||
property to `false`:
|
||||
By default, Spring Boot's Devtools module, `org.springframework.boot:spring-boot-devtools`, will be excluded from an executable jar or war.
|
||||
If you want to include Devtools in your archive set the `excludeDevtools` property to `false`:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -195,14 +177,11 @@ include::../gradle/packaging/boot-war-include-devtools.gradle.kts[tags=include-d
|
||||
[[packaging-executable-configuring-unpacking]]
|
||||
==== Configuring libraries that require unpacking
|
||||
|
||||
Most libraries can be used directly when nested in an executable archive, however certain
|
||||
libraries can have problems. For example, JRuby includes its own nested jar support which
|
||||
assumes that `jruby-complete.jar` is always directly available on the file system.
|
||||
Most libraries can be used directly when nested in an executable archive, however certain libraries can have problems.
|
||||
For example, JRuby includes its own nested jar support which assumes that `jruby-complete.jar` is always directly available on the file system.
|
||||
|
||||
To deal with any problematic libraries, an executable archive can be configured to unpack
|
||||
specific nested jars to a temporary folder when the executable archive is run. Libraries
|
||||
can be identified as requiring unpacking using Ant-style patterns that match against
|
||||
the absolute path of the source jar file:
|
||||
To deal with any problematic libraries, an executable archive can be configured to unpack specific nested jars to a temporary folder when the executable archive is run.
|
||||
Libraries can be identified as requiring unpacking using Ant-style patterns that match against the absolute path of the source jar file:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -217,18 +196,17 @@ include::../gradle/packaging/boot-jar-requires-unpack.gradle.kts[tags=requires-u
|
||||
----
|
||||
|
||||
|
||||
For more control a closure can also be used. The closure is passed a `FileTreeElement`
|
||||
and should return a `boolean` indicating whether or not unpacking is required.
|
||||
For more control a closure can also be used.
|
||||
The closure is passed a `FileTreeElement` and should return a `boolean` indicating whether or not unpacking is required.
|
||||
|
||||
|
||||
|
||||
[[packaging-executable-configuring-launch-script]]
|
||||
==== Making an archive fully executable
|
||||
|
||||
Spring Boot provides support for fully executable archives. An archive is made fully
|
||||
executable by prepending a shell script that knows how to launch the application. On
|
||||
Unix-like platforms, this launch script allows the archive to be run directly like any
|
||||
other executable or to be installed as a service.
|
||||
Spring Boot provides support for fully executable archives.
|
||||
An archive is made fully executable by prepending a shell script that knows how to launch the application.
|
||||
On Unix-like platforms, this launch script allows the archive to be run directly like any other executable or to be installed as a service.
|
||||
|
||||
To use this feature, the inclusion of the launch script must be enabled:
|
||||
|
||||
@ -245,9 +223,9 @@ include::../gradle/packaging/boot-jar-include-launch-script.gradle.kts[tags=incl
|
||||
----
|
||||
|
||||
|
||||
This will add Spring Boot's default launch script to the archive. The default launch
|
||||
script includes several properties with sensible default values. The values can be
|
||||
customized using the `properties` property:
|
||||
This will add Spring Boot's default launch script to the archive.
|
||||
The default launch script includes several properties with sensible default values.
|
||||
The values can be customized using the `properties` property:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -262,8 +240,7 @@ include::../gradle/packaging/boot-jar-launch-script-properties.gradle.kts[tags=l
|
||||
----
|
||||
|
||||
|
||||
If the default launch script does not meet your needs, the `script` property can be used
|
||||
to provide a custom launch script:
|
||||
If the default launch script does not meet your needs, the `script` property can be used to provide a custom launch script:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -281,8 +258,7 @@ include::../gradle/packaging/boot-jar-custom-launch-script.gradle.kts[tags=custo
|
||||
[[packaging-executable-configuring-properties-launcher]]
|
||||
==== 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"]
|
||||
.Groovy
|
||||
|
@ -6,11 +6,9 @@
|
||||
[[publishing-your-application-maven]]
|
||||
=== 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. 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:
|
||||
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.
|
||||
The `uploadBootArchives` task can be configured to publish the archive to a Maven repository:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -28,10 +26,9 @@ include::../gradle/publishing/maven.gradle.kts[tags=upload]
|
||||
[[publishing-your-application-maven-publish]]
|
||||
=== 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`. 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:
|
||||
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.
|
||||
For example, to publish the artifact produced by the default `bootJar` task:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -49,9 +46,7 @@ include::../gradle/publishing/maven-publish.gradle.kts[tags=publishing]
|
||||
[[publishing-your-application-distribution]]
|
||||
=== Distributing with the `application` plugin
|
||||
|
||||
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. Zip and tar
|
||||
distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively. To
|
||||
use the `application` plugin, its `mainClassName` project property must be configured
|
||||
with the name of your application's main class.
|
||||
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.
|
||||
Zip and tar distributions can be built by the `bootDistZip` and `bootDistTar` tasks respectively.
|
||||
To use the `application` plugin, its `mainClassName` project property must be configured with the name of your application's main class.
|
||||
|
@ -1,27 +1,22 @@
|
||||
[[reacting-to-other-plugins]]
|
||||
== Reacting to other plugins
|
||||
|
||||
When another plugin is applied the Spring Boot plugin reacts by making various changes
|
||||
to the project's configuration. This section describes those changes.
|
||||
When another plugin is applied the Spring Boot plugin reacts by making various changes to the project's configuration.
|
||||
This section describes those changes.
|
||||
|
||||
|
||||
|
||||
[[reacting-to-other-plugins-java]]
|
||||
=== 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. The jar will contain everything on the runtime
|
||||
classpath of the main source set; classes are packaged in `BOOT-INF/classes` and jars
|
||||
are packaged in `BOOT-INF/lib`
|
||||
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
|
||||
The jar will contain everything on the runtime classpath of the main source set; classes are packaged in `BOOT-INF/classes` and jars are packaged in `BOOT-INF/lib`
|
||||
2. Configures the `assemble` task to depend on the `bootJar` task.
|
||||
3. Disables the `jar` task.
|
||||
4. Creates a {boot-run-javadoc}[`BootRun`] task named `bootRun` that can be used to run
|
||||
your application.
|
||||
5. Creates a configuration named `bootArchives` that contains the artifact produced by
|
||||
the `bootJar` task.
|
||||
4. Creates a {boot-run-javadoc}[`BootRun`] task named `bootRun` that can be used to run your application.
|
||||
5. Creates a configuration named `bootArchives` that contains the artifact produced by the `bootJar` task.
|
||||
6. Configures any `JavaCompile` tasks with no configured encoding to use `UTF-8`.
|
||||
7. Configures any `JavaCompile` tasks to use the `-parameters` compiler argument.
|
||||
|
||||
@ -30,12 +25,10 @@ plugin:
|
||||
[[reacting-to-other-plugins-kotlin]]
|
||||
=== Reacting to the Kotlin plugin
|
||||
|
||||
When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring Boot
|
||||
plugin:
|
||||
When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring Boot plugin:
|
||||
|
||||
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version
|
||||
of the plugin. This is achieved by setting the `kotlin.version` property with a value
|
||||
that matches the version of the Kotlin plugin.
|
||||
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version of the plugin.
|
||||
This is achieved by setting the `kotlin.version` property with a value that matches the version of the Kotlin plugin.
|
||||
2. Configures any `KotlinCompile` tasks to use the `-java-parameters` compiler argument.
|
||||
|
||||
|
||||
@ -45,52 +38,37 @@ 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. In addition to the standard packaging, everything
|
||||
in the `providedRuntime` configuration will be packaged in `WEB-INF/lib-provided`.
|
||||
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an executable, fat war for the project.
|
||||
In addition to the standard packaging, everything in the `providedRuntime` configuration will be packaged in `WEB-INF/lib-provided`.
|
||||
2. Configures the `assemble` task to depend on the `bootWar` task.
|
||||
3. Disables the `war` task.
|
||||
4. Configures the `bootArchives` configuration to contain the artifact produced by the
|
||||
`bootWar` task.
|
||||
4. Configures the `bootArchives` configuration to contain the artifact produced by the `bootWar` task.
|
||||
|
||||
|
||||
|
||||
[[reacting-to-other-plugins-dependency-management]]
|
||||
=== Reacting to the dependency management plugin
|
||||
|
||||
When the {dependency-management-plugin}[`io.spring.dependency-management` plugin] is
|
||||
applied to a project, the Spring Boot plugin will automatically import the
|
||||
`spring-boot-dependencies` bom.
|
||||
When the {dependency-management-plugin}[`io.spring.dependency-management` plugin] is applied to a project, the Spring Boot plugin will automatically import the `spring-boot-dependencies` bom.
|
||||
|
||||
|
||||
|
||||
[[reacting-to-other-plugins-application]]
|
||||
=== 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`. The
|
||||
task is configured to use the `applicationDefaultJvmArgs` property as a convention
|
||||
for its `defaultJvmOpts` property.
|
||||
2. Creates a new distribution named `boot` and configures it to contain the artifact in
|
||||
the `bootArchives` configuration in its `lib` directory and the start scripts in its
|
||||
`bin` directory.
|
||||
3. Configures the `bootRun` task to use the `mainClassName` property as a convention for
|
||||
its `main` property.
|
||||
4. Configures the `bootRun` task to use the `applicationDefaultJvmArgs` property as a
|
||||
convention for its `jvmArgs` property.
|
||||
5. Configures the `bootJar` task to use the `mainClassName` property as a convention for
|
||||
the `Start-Class` entry in its manifest.
|
||||
6. Configures the `bootWar` task to use the `mainClassName` property as a convention for
|
||||
the `Start-Class` entry in its manifest.
|
||||
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
|
||||
The task is configured to use the `applicationDefaultJvmArgs` property as a convention for its `defaultJvmOpts` property.
|
||||
2. Creates a new distribution named `boot` and configures it to contain the artifact in the `bootArchives` configuration in its `lib` directory and the start scripts in its `bin` directory.
|
||||
3. Configures the `bootRun` task to use the `mainClassName` property as a convention for its `main` property.
|
||||
4. Configures the `bootRun` task to use the `applicationDefaultJvmArgs` property as a convention for its `jvmArgs` property.
|
||||
5. Configures the `bootJar` task to use the `mainClassName` property as a convention for the `Start-Class` entry in its manifest.
|
||||
6. Configures the `bootWar` task to use the `mainClassName` property as a convention for the `Start-Class` entry in its manifest.
|
||||
|
||||
|
||||
|
||||
[[reacting-to-other-plugins-maven]]
|
||||
=== 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.
|
||||
|
@ -8,14 +8,11 @@ To run your application without first building an archive use the `bootRun` task
|
||||
$ ./gradlew bootRun
|
||||
----
|
||||
|
||||
The `bootRun` task is an instance of
|
||||
{boot-run-javadoc}[`BootRun`] which is a `JavaExec` subclass. As such, all of the
|
||||
{gradle-dsl}/org.gradle.api.tasks.JavaExec.html[usual configuration options] for executing
|
||||
a Java process in Gradle are available to you. The task is automatically configured to use
|
||||
the runtime classpath of the main source set.
|
||||
The `bootRun` task is an instance of {boot-run-javadoc}[`BootRun`] which is a `JavaExec` subclass.
|
||||
As such, all of the {gradle-dsl}/org.gradle.api.tasks.JavaExec.html[usual configuration options] for executing a Java process in Gradle are available to you.
|
||||
The task is automatically configured to use the runtime classpath of the main source set.
|
||||
|
||||
By default, the main class will be configured automatically by looking for a class with a
|
||||
`public static void main(String[])` method in directories on the task's classpath.
|
||||
By default, the main class will be configured automatically by looking for a class with a `public static void main(String[])` method in directories on the task's classpath.
|
||||
|
||||
The main class can also be configured explicitly using the task's `main` property:
|
||||
|
||||
@ -32,8 +29,7 @@ include::../gradle/running/boot-run-main.gradle.kts[tags=main]
|
||||
----
|
||||
|
||||
|
||||
Alternatively, the main class name can be configured project-wide using the
|
||||
`mainClassName` property of the Spring Boot DSL:
|
||||
Alternatively, the main class name can be configured project-wide using the `mainClassName` property of the Spring Boot DSL:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -48,8 +44,7 @@ include::../gradle/running/spring-boot-dsl-main-class-name.gradle.kts[tags=main-
|
||||
----
|
||||
|
||||
|
||||
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName`
|
||||
project property must be configured and can be used for the same purpose:
|
||||
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName` project property must be configured and can be used for the same purpose:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -66,25 +61,22 @@ include::../gradle/running/application-plugin-main-class-name.gradle.kts[tags=ma
|
||||
|
||||
[[running-your-application-passing-arguments]]
|
||||
=== Passing arguments to your application
|
||||
Like all `JavaExec` tasks, arguments can be passed into `bootRun` from the command line
|
||||
using `--args='<arguments>'` when using Gradle 4.9 or later. For example, to run your
|
||||
application with a profile named `dev` active the following command can be used:
|
||||
Like all `JavaExec` tasks, arguments can be passed into `bootRun` from the command line using `--args='<arguments>'` when using Gradle 4.9 or later.
|
||||
For example, to run your application with a profile named `dev` active the following command can be used:
|
||||
|
||||
[source,bash,indent=0,subs="verbatim"]
|
||||
----
|
||||
$ ./gradlew bootRun --args='--spring.profiles.active=dev'
|
||||
----
|
||||
|
||||
See {gradle-api}/org/gradle/api/tasks/JavaExec.html#setArgsString-java.lang.String-[the
|
||||
javadoc for `JavaExec.setArgsString`] for further details.
|
||||
See {gradle-api}/org/gradle/api/tasks/JavaExec.html#setArgsString-java.lang.String-[the javadoc for `JavaExec.setArgsString`] for further details.
|
||||
|
||||
|
||||
|
||||
[[running-your-application-reloading-resources]]
|
||||
=== Reloading resources
|
||||
If devtools has been added to your project it will automatically monitor your
|
||||
application for changes. Alternatively, you can configure `bootRun` such that your
|
||||
application's static resources are loaded from their source location:
|
||||
If devtools has been added to your project it will automatically monitor your application for changes.
|
||||
Alternatively, you can configure `bootRun` such that your application's static resources are loaded from their source location:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Groovy
|
||||
@ -99,5 +91,4 @@ include::../gradle/running/boot-run-source-resources.gradle.kts[tags=source-reso
|
||||
----
|
||||
|
||||
|
||||
This makes them reloadable in the live application which can be helpful at development
|
||||
time.
|
||||
This makes them reloadable in the live application which can be helpful at development time.
|
||||
|
Loading…
Reference in New Issue
Block a user