Running your Application with Gradle
To run your application without first building an archive use the bootRun
task:
$ ./gradlew bootRun
The bootRun
task is an instance of BootRun
which is a JavaExec
subclass.
As such, all of the 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 the main source set’s output.
The main class can also be configured explicitly using the task’s main
property:
-
Groovy
-
Kotlin
tasks.named("bootRun") {
mainClass = 'com.example.ExampleApplication'
}
tasks.named<BootRun>("bootRun") {
mainClass.set("com.example.ExampleApplication")
}
Alternatively, the main class name can be configured project-wide using the mainClass
property of the Spring Boot DSL:
-
Groovy
-
Kotlin
springBoot {
mainClass = 'com.example.ExampleApplication'
}
springBoot {
mainClass.set("com.example.ExampleApplication")
}
By default, bootRun
will configure the JVM to optimize its launch for faster startup during development.
This behavior can be disabled by using the optimizedLaunch
property, as shown in the following example:
-
Groovy
-
Kotlin
tasks.named("bootRun") {
optimizedLaunch = false
}
tasks.named<BootRun>("bootRun") {
optimizedLaunch.set(false)
}
If the application
plugin has been applied, its mainClass
property must be configured and can be used for the same purpose:
-
Groovy
-
Kotlin
application {
mainClass = 'com.example.ExampleApplication'
}
application {
mainClass.set("com.example.ExampleApplication")
}
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:
$ ./gradlew bootRun --args='--spring.profiles.active=dev'
See the javadoc for JavaExec.setArgsString
for further details.
Passing System Properties to Your application
Since bootRun
is a standard JavaExec
task, system properties can be passed to the application’s JVM by specifying them in the build script.
To make that value of a system property to be configurable set its value using a project property.
To allow a project property to be optional, reference it using findProperty
.
Doing so also allows a default value to be provided using the ?:
Elvis operator, as shown in the following example:
-
Groovy
-
Kotlin
tasks.named("bootRun") {
systemProperty 'com.example.property', findProperty('example') ?: 'default'
}
tasks.named<BootRun>("bootRun") {
systemProperty("com.example.property", findProperty("example") ?: "default")
}
The preceding example sets that com.example.property
system property to the value of the example
project property.
If the example
project property has not been set, the value of the system property will be default
.
Gradle allows project properties to be set in a variety of ways, including on the command line using the -P
flag, as shown in the following example:
$ ./gradlew bootRun -Pexample=custom
The preceding example sets the value of the example
project property to custom
.
bootRun
will then use this as the value of the com.example.property
system property.
Reloading Resources
If devtools has been added to your project it will automatically monitor your application’s classpath for changes. Note that modified files need to be recompiled for the classpath to update in order to trigger reloading with devtools. For more details on using devtools, refer to this section of the reference documentation.
Alternatively, you can configure bootRun
such that your application’s static resources are loaded from their source location:
-
Groovy
-
Kotlin
tasks.named("bootRun") {
sourceResources sourceSets.main
}
tasks.named<BootRun>("bootRun") {
sourceResources(sourceSets["main"])
}
This makes them reloadable in the live application which can be helpful at development time.
Using a Test Main Class
In addition to bootRun
a bootTestRun
task is also registered.
Like bootRun
, bootTestRun
is an instance of BootRun
but it’s configured to use a main class found in the output of the test source set rather than the main source set.
It also uses the test source set’s runtime classpath rather than the main source set’s runtime classpath.
As bootTestRun
is an instance of BootRun
, all of the configuration options described above for bootRun
can also be used with bootTestRun
.