To retrieve the health of a particular component of the application's health, make a
To retrieve the health of a particular component of the application's health, make a `GET` request to `/actuator/health/\{component}`, as shown in the following curl-based example:
`GET` request to `/actuator/health/\{component}`, as shown in the following curl-based
If a particular component contains other nested components (as the `broker` indicator in
If a particular component contains other nested components (as the `broker` indicator in the example above), the health of such a nested component can be retrieved by issuing a `GET` request to `/actuator/health/\{component}/\{subcomponent}`, as shown in the following curl-based example:
the example above), the health of such a nested component can be retrieved by issuing a
`GET` request to `/actuator/health/\{component}/\{subcomponent}`, as shown in the following
The response contains all Spring Integration components used within the application, as
The response contains all Spring Integration components used within the application, as well as the links between them.
well as the links between them. More information about the structure can be found in the
More information about the structure can be found in the https://docs.spring.io/spring-integration/reference/html/#integration-graph[reference documentation].
NOTE: Retrieving part of the log file is not supported when using Jersey.
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
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:
the `Range` header, as shown in the following curl-based example:
To set the level of a logger, make a `POST` request to
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:
`/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
To set the level of a logger, make a `POST` request to `/actuator/loggers/{group.name}` with a JSON body that specifies the configured level for the logger group, as shown in the following curl-based example:
`/actuator/loggers/{group.name}` with a JSON body that specifies the configured level
for the logger group, as shown in the following curl-based example:
To clear the level of a logger, make a `POST` request to
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:
`/actuator/loggers/{logger.name}` with a JSON body containing an empty object, as shown
To drill down into a metric, make a `GET` request to `/actuator/metrics/{metric.name}`
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:
using the `tag` query parameter, as shown in the following curl-based example:
The preceding example retrieves the `jvm.memory.max` metric, where the `area` tag has a
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`.
value of `nonheap` and the `id` attribute has a value of `Compressed Class Space`. The
The resulting response is similar to the following:
@ -8,8 +8,7 @@ The `threaddump` endpoint provides a thread dump from the application's JVM.
[[threaddump-retrieving-json]]
[[threaddump-retrieving-json]]
== Retrieving the Thread Dump as JSON
== Retrieving the Thread Dump as JSON
To retrieve the thread dump as JSON, make a `GET` request to `/actuator/threaddump` with
To retrieve the thread dump as JSON, make a `GET` request to `/actuator/threaddump` with an appropriate `Accept` header, as shown in the following curl-based example:
an appropriate `Accept` header, as shown in the following curl-based example:
To get started with the plugin it needs to be applied to your project.
To get started with the plugin it needs to be applied to your project.
ifeval::["{version-type}" == "RELEASE"]
ifeval::["{version-type}" == "RELEASE"]
The plugin is https://plugins.gradle.org/plugin/org.springframework.boot[published to
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:
Gradle's plugin portal] and can be applied using the `plugins` block:
Applied in isolation the plugin makes few changes to a project. Instead, the plugin
Applied in isolation the plugin makes few changes to a project.
detects when certain other plugins are applied and reacts accordingly. For example, when
Instead, the plugin detects when certain other plugins are applied and reacts accordingly.
the `java` plugin is applied a task for building an executable jar is automatically
For example, when the `java` plugin is applied a task for building an executable jar is automatically configured.
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:
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
To learn more about how the Spring Boot plugin behaves when other plugins are applied
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>>.
please see the section on <<reacting-to-other-plugins, reacting to other plugins>>.
The Spring Boot Gradle Plugin provides Spring Boot support in https://gradle.org[Gradle],
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
It allows you to package executable jar or war archives, run Spring Boot applications, and use the dependency management provided by `spring-boot-dependencies`.
use the dependency management provided by `spring-boot-dependencies`. Spring Boot's
Spring Boot's Gradle plugin requires Gradle 5.x (4.10 is also supported but this support is deprecated and will be removed in a future release).
Gradle plugin requires Gradle 5.x (4.10 is also supported but this support is deprecated
and will be removed in a future release).
In addition to this user guide, {api-documentation}[API documentation] is also available.
In addition to this user guide, {api-documentation}[API documentation] is also available.
Spring Boot Actuator's `info` endpoint automatically publishes information about your
Spring Boot Actuator's `info` endpoint automatically publishes information about your build in the presence of a `META-INF/build-info.properties` file.
build in the presence of a `META-INF/build-info.properties` file. A
A {build-info-javadoc}[`BuildInfo`] task is provided to generate this file.
{build-info-javadoc}[`BuildInfo`] task is provided to generate this file. The easiest way
The easiest way to use the task is via the plugin's DSL:
This will configure a {build-info-javadoc}[`BuildInfo`] task named `bootBuildInfo` and, if
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.
it exists, make the Java plugin's `classes` task depend upon it. The task's destination
The task's destination directory will be `META-INF` in the output directory of the main source set's resources (typically `build/resources/main`).
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:
By default, the generated build information is derived from the project:
When you apply the {dependency-management-plugin}[`io.spring.dependency-management`]
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.
plugin, Spring Boot's plugin will
This provides a similar dependency management experience to the one that's enjoyed by Maven users.
automatically <<reacting-to-other-plugins-dependency-management,import the
For example, it allows you to omit version numbers when declaring dependencies that are managed in the bom.
`spring-boot-dependencies` bom>> from the version of Spring Boot that you are using.
To make use of this functionality, simply declare dependencies in the usual way but omit the version number:
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:
The `spring-boot-dependencies` bom that is automatically imported when the dependency
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.
management plugin is applied uses properties to control the versions of the dependencies
Please refer to the {github-code}/spring-boot-project/spring-boot-dependencies/pom.xml[bom] for a complete list of these properties.
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
To customize a managed version you set its corresponding property.
customize the version of SLF4J which is controlled by the `slf4j.version` property:
For example, to customize the version of SLF4J which is controlled by the `slf4j.version` property:
WARNING: Each Spring Boot release is designed and tested against a specific set of
WARNING: Each Spring Boot release is designed and tested against a specific set of third-party dependencies.
third-party dependencies. Overriding versions may cause compatibility issues and should
Overriding versions may cause compatibility issues and should be done with care.
be done with care.
[[managing-dependencies-using-in-isolation]]
[[managing-dependencies-using-in-isolation]]
=== Using Spring Boot's dependency management in isolation
=== Using Spring Boot's dependency management in isolation
Spring Boot's dependency management can be used in a project without applying Spring
Spring Boot's dependency management can be used in a project without applying Spring Boot's plugin to that project.
Boot's plugin to that project. The `SpringBootPlugin` class provides a `BOM_COORDINATES`
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.
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:
First, configure the project to depend on the Spring Boot plugin but do not apply it:
The Spring Boot plugin's dependency on the dependency management plugin means that you
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.
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.
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:
Apply the dependency management plugin and then configure it to import Spring Boot's bom:
The Kotlin code above is a bit awkward. That's because we're using the imperative way of
The Kotlin code above is a bit awkward.
applying the dependency management plugin.
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
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.
by using the `plugins` block as we're doing for the Spring Boot plugin. A downside of this
A downside of this method is that it forces us to specify the version of the dependency management plugin:
method is that it forces us to specify the version of the dependency management plugin:
To learn more about the capabilities of the dependency management plugin, please refer to
To learn more about the capabilities of the dependency management plugin, please refer to its {dependency-management-plugin-documentation}[documentation].
its {dependency-management-plugin-documentation}[documentation].
The plugin can create executable archives (jar files and war files) that contain all of
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`.
an application's dependencies and can then be run with `java -jar`.
[[packaging-executable-jars]]
[[packaging-executable-jars]]
=== Packaging executable jars
=== Packaging executable jars
Executable jars can be built using the `bootJar` task. The task is automatically created
Executable jars can be built using the `bootJar` task.
when the `java` plugin is applied and is an instance of {boot-jar-javadoc}[`BootJar`].
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
The `assemble` task is automatically configured to depend upon the `bootJar` task so running `assemble` (or `build`) will also run the `bootJar` task.
running `assemble` (or `build`) will also run the `bootJar` task.
[[packaging-executable-wars]]
[[packaging-executable-wars]]
=== Packaging executable wars
=== Packaging executable wars
Executable wars can be built using the `bootWar` task. The task is automatically created
Executable wars can be built using the `bootWar` task.
when the `war` plugin is applied and is an instance of {boot-war-javadoc}[`BootWar`].
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
The `assemble` task is automatically configured to depend upon the `bootWar` task so running `assemble` (or `build`) will also run the `bootWar` task.
running `assemble` (or `build`) will also run the `bootWar` task.
[[packaging-executable-wars-deployable]]
[[packaging-executable-wars-deployable]]
==== Packaging executable and deployable wars
==== Packaging executable and deployable wars
A war file can be packaged such that it can be executed using `java -jar` and deployed
A war file can be packaged such that it can be executed using `java -jar` and deployed to an external container.
to an external container. To do so, the embedded servlet container dependencies should
To do so, the embedded servlet container dependencies should be added to the `providedRuntime` configuration, for example:
be added to the `providedRuntime` configuration, for example:
This ensures that they are package in the war file's `WEB-INF/lib-provided` directory
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.
from where they will not conflict with the external container's own classes.
NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among
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.
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]]
=== Packaging executable and normal archives
=== Packaging executable and normal archives
By default, when the `bootJar` or `bootWar` tasks are configured, the `jar` or `war`
By default, when the `bootJar` or `bootWar` tasks are configured, the `jar` or `war` tasks are disabled.
tasks are disabled. A project can be configured to build both an executable archive
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:
and a normal archive at the same time by enabling the `jar` or `war` task:
To avoid the executable archive and the normal archive from being written to the same
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.
location, one or the other should be configured to use a different location. One way to
The {boot-jar-javadoc}[`BootJar`] and {boot-war-javadoc}[`BootWar`] tasks are subclasses
The {boot-jar-javadoc}[`BootJar`] and {boot-war-javadoc}[`BootWar`] tasks are subclasses of Gradle's `Jar` and `War` tasks respectively.
of Gradle's `Jar` and `War` tasks respectively. As a result, all of the standard
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.
configuration options that are available when packaging a jar or war are also available
A number of configuration options that are specific to executable jars and wars are also provided.
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]]
[[packaging-executable-configuring-main-class]]
==== Configuring the main class
==== Configuring the main class
By default, the executable archive's main class will be configured automatically by
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.
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`
The main class can also be configured explicitly using the task's `mainClassName` property:
If the {application-plugin}[`application` plugin] has been applied its `mainClassName`
If the {application-plugin}[`application` plugin] has been applied its `mainClassName` project property must be configured and can be used for the same purpose:
project property must be configured and can be used for the same purpose:
Most libraries can be used directly when nested in an executable archive, however certain
Most libraries can be used directly when nested in an executable archive, however certain libraries can have problems.
libraries can have problems. For example, JRuby includes its own nested jar support which
For example, JRuby includes its own nested jar support which assumes that `jruby-complete.jar` is always directly available on the file system.
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
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.
specific nested jars to a temporary folder when the executable archive is run. Libraries
Libraries can be identified as requiring unpacking using Ant-style patterns that match against the absolute path of the source jar file:
can be identified as requiring unpacking using Ant-style patterns that match against
When the {maven-plugin}[`maven` plugin] is applied, an `Upload` task for the
When the {maven-plugin}[`maven` plugin] is applied, an `Upload` task for the `bootArchives` configuration named `uploadBootArchives` is automatically created.
`bootArchives` configuration named `uploadBootArchives` is automatically created. By
By default, the `bootArchives` configuration contains the archive produced by the `bootJar` or `bootWar` task.
default, the `bootArchives` configuration contains the archive produced by the `bootJar`
The `uploadBootArchives` task can be configured to publish the archive to a Maven repository:
or `bootWar` task. The `uploadBootArchives` task can be configured to publish the archive
When another plugin is applied the Spring Boot plugin reacts by making various changes
When another plugin is applied the Spring Boot plugin reacts by making various changes to the project's configuration.
to the project's configuration. This section describes those changes.
This section describes those changes.
[[reacting-to-other-plugins-java]]
[[reacting-to-other-plugins-java]]
=== Reacting to the Java plugin
=== Reacting to the Java plugin
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot plugin:
plugin:
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
executable, fat jar for the project. The jar will contain everything on the runtime
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`
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.
2. Configures the `assemble` task to depend on the `bootJar` task.
3. Disables the `jar` task.
3. Disables the `jar` task.
4. Creates a {boot-run-javadoc}[`BootRun`] task named `bootRun` that can be used to run
4. Creates a {boot-run-javadoc}[`BootRun`] task named `bootRun` that can be used to run your application.
your application.
5. Creates a configuration named `bootArchives` that contains the artifact produced by the `bootJar` task.
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`.
6. Configures any `JavaCompile` tasks with no configured encoding to use `UTF-8`.
7. Configures any `JavaCompile` tasks to use the `-parameters` compiler argument.
7. Configures any `JavaCompile` tasks to use the `-parameters` compiler argument.
@ -30,12 +25,10 @@ plugin:
[[reacting-to-other-plugins-kotlin]]
[[reacting-to-other-plugins-kotlin]]
=== Reacting to the Kotlin plugin
=== Reacting to the Kotlin plugin
When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring Boot
When {kotlin-plugin}[Kotlin's Gradle plugin] is applied to a project, the Spring Boot plugin:
plugin:
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version
1. Aligns the Kotlin version used in Spring Boot's dependency management with the version of the plugin.
of the plugin. This is achieved by setting the `kotlin.version` property with a value
This is achieved by setting the `kotlin.version` property with a value that matches the version of the Kotlin plugin.
that matches the version of the Kotlin plugin.
2. Configures any `KotlinCompile` tasks to use the `-java-parameters` compiler argument.
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:
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
1. Creates a {boot-war-javadoc}[`BootWar`] task named `bootWar` that will create an executable, fat war for the project.
executable, fat war for the project. In addition to the standard packaging, everything
In addition to the standard packaging, everything in the `providedRuntime` configuration will be packaged in `WEB-INF/lib-provided`.
in the `providedRuntime` configuration will be packaged in `WEB-INF/lib-provided`.
2. Configures the `assemble` task to depend on the `bootWar` task.
2. Configures the `assemble` task to depend on the `bootWar` task.
3. Disables the `war` task.
3. Disables the `war` task.
4. Configures the `bootArchives` configuration to contain the artifact produced by the
4. Configures the `bootArchives` configuration to contain the artifact produced by the `bootWar` task.
When the {dependency-management-plugin}[`io.spring.dependency-management` plugin] is
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.
applied to a project, the Spring Boot plugin will automatically import the
`spring-boot-dependencies` bom.
[[reacting-to-other-plugins-application]]
[[reacting-to-other-plugins-application]]
=== Reacting to the application plugin
=== Reacting to the application plugin
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the
When Gradle's {application-plugin}[`application` plugin] is applied to a project, the Spring Boot plugin:
Spring Boot plugin:
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts
1. Creates a `CreateStartScripts` task named `bootStartScripts` that will create scripts that launch the artifact in the `bootArchives` configuration using `java -jar`.
that launch the artifact in the `bootArchives` configuration using `java -jar`. The
The task is configured to use the `applicationDefaultJvmArgs` property as a convention for its `defaultJvmOpts` property.
task is configured to use the `applicationDefaultJvmArgs` property as a convention
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.
for its `defaultJvmOpts` property.
3. Configures the `bootRun` task to use the `mainClassName` property as a convention for its `main` property.
2. Creates a new distribution named `boot` and configures it to contain the artifact in
4. Configures the `bootRun` task to use the `applicationDefaultJvmArgs` property as a convention for its `jvmArgs` property.
the `bootArchives` configuration in its `lib` directory and the start scripts in its
5. Configures the `bootJar` task to use the `mainClassName` property as a convention for the `Start-Class` entry in its manifest.
`bin` directory.
6. Configures the `bootWar` task to use the `mainClassName` property as a convention for the `Start-Class` entry in its manifest.
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-other-plugins-maven]]
=== Reacting to the Maven plugin
=== Reacting to the Maven plugin
When Gradle's {maven-plugin}[`maven` plugin] is applied to a project, the Spring Boot
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.
plugin will configure the `uploadBootArchives` `Upload` task to ensure that no
dependencies are declared in the pom that it generates.
@ -8,13 +8,11 @@ To run your application without first building an archive use the `bootRun` task
$ ./gradlew bootRun
$ ./gradlew bootRun
----
----
The `bootRun` task is an instance of {boot-run-javadoc}[`BootRun`] which is a `JavaExec`
The `bootRun` task is an instance of {boot-run-javadoc}[`BootRun`] which is a `JavaExec` subclass.
subclass. As such, all of the {gradle-dsl}/org.gradle.api.tasks.JavaExec.html[usual
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.
configuration options] for executing a Java process in Gradle are available to you. The
The task is automatically configured to use the runtime classpath of the main source set.
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
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.
`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:
The main class can also be configured explicitly using the task's `main` property:
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName`
If the {application-plugin}[`application` plugin] has been applied, its `mainClassName` project property must be configured and can be used for the same purpose:
project property must be configured and can be used for the same purpose:
Andy Wilkinson
5 years ago