To use the Spring Boot Gradle Plugin configure it using the plugins block:

plugins {
    id 'org.springframework.boot' version '1.5.2.RELEASE'
}

The spring-boot plugin automatically applies the Dependency Management Plugin and configures it to import the spring-boot-starter-parent bom. This provides a similar dependency management experience to the one that is 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 leave the version number empty:

dependencies {
    compile("org.springframework.boot:spring-boot-starter-web")
    compile("org.thymeleaf:thymeleaf-spring4")
    compile("nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect")
}

	Note
	The version of the spring-boot gradle plugin that you declare determines the version of the spring-boot-starter-parent bom that is imported (this ensures that builds are always repeatable). You should always set the version of the spring-boot gradle plugin to the actual Spring Boot version that you wish to use. Details of the versions that are provided can be found in the appendix .

To learn more about the capabilities of the Dependency Management Plugin, please refer to its documentation .

Once the spring-boot plugin has been applied to your project it will automatically attempt to rewrite archives to make them executable using the bootRepackage task . You should configure your project to build a jar or war (as appropriate) in the usual way.

The main class that you want to launch can either be specified using a configuration option, or by adding a Main-Class attribute to the manifest. If you don’t specify a main class the plugin will search for a class with a public static void main(String[] args) method.

	Tip
	Check Section 67.6, “Repackage configuration” for a full list of configuration options.

To build and run a project artifact, you can type the following:

$ gradle build
$ java -jar build/libs/mymodule-0.0.1-SNAPSHOT.jar

To build a war file that is both executable and deployable into an external container, you need to mark the embedded container dependencies as belonging to the war plugin’s providedRuntime configuration, e.g.:

...
apply plugin: 'war'
war {
    baseName = 'myapp'
    version =  '0.5.0'
repositories {
    jcenter()
    maven { url "http://repo.spring.io/libs-snapshot" }
dependencies {
    compile("org.springframework.boot:spring-boot-starter-web")
    providedRuntime("org.springframework.boot:spring-boot-starter-tomcat")
}

	Tip
	See the “ Section 85.1, “Create a deployable war file” ” section for more details on how to create a deployable war file.

To run a project in place without building a jar first you can use the “bootRun” task:

$ gradle bootRun

If devtools has been added to your project it will automatically monitor your application for changes. Alternatively, you can also run the application so that your static classpath resources (i.e. in src/main/resources by default) are reloadable in the live application, which can be helpful at development time.

bootRun {
    addResources = true
}

Making static classpath resources reloadable means that bootRun does not use the output of the processResources task, i.e., when invoked using bootRun , your application will use the resources in their unprocessed form.

The gradle plugin automatically extends your build script DSL with a springBoot element for global configuration of the Boot plugin. Set the appropriate properties as you would with any other Gradle extension (see below for a list of configuration options):

springBoot {
    backupSource = false
}

The plugin adds a bootRepackage task which you can also configure directly, e.g.:

bootRepackage {
    mainClass = 'demo.Application'
}

The following configuration options are available:

Sometimes it may be more appropriate to not package default dependencies resolved from compile , runtime and provided scopes. If the created executable jar file is intended to be run as it is, you need to have all dependencies nested inside it; however, if the plan is to explode a jar file and run the main class manually, you may already have some of the libraries available via CLASSPATH . This is a situation where you can repackage your jar with a different set of dependencies.

Using a custom configuration will automatically disable dependency resolving from compile , runtime and provided scopes. Custom configuration can be either defined globally (inside the springBoot section) or per task.

task clientJar(type: Jar) {
    appendix = 'client'
    from sourceSets.main.output
    exclude('**/*Something*')
task clientBoot(type: BootRepackage, dependsOn: clientJar) {
    withJarTask = clientJar
    customConfiguration = "mycustomconfiguration"
}

In above example, we created a new clientJar Jar task to package a customized file set from your compiled sources. Then we created a new clientBoot BootRepackage task and instructed it to work with only clientJar task and mycustomconfiguration .

configurations {
    mycustomconfiguration.exclude group: 'log4j'
dependencies {
    mycustomconfiguration configurations.runtime
}

The configuration that we are referring to in BootRepackage is a normal Gradle configuration . In the above example we created a new configuration named mycustomconfiguration instructing it to derive from a runtime and exclude the log4j group. If the clientBoot task is executed, the repackaged boot jar will have all dependencies from runtime but no log4j jars.

67.7.3 Using a custom layout

If you have custom requirements for how to arrange the dependencies and loader classes inside the repackaged jar, you can use a custom layout. Any library which defines one or more LayoutFactory implementations can be added to the build script dependencies and then the layout factory becomes available in the springBoot configuration. For example:

buildscript {
	repositories {
		mavenCentral()
	dependencies {
		classpath("org.springframework.boot:spring-boot-gradle-plugin:1.5.2.RELEASE")
		classpath("com.example:custom-layout:1.0.0")
springBoot {
	layoutFactory = new com.example.CustomLayoutFactory()
}

	Note
	If there is only one custom LayoutFactory on the build classpath and it is listed in META-INF/spring.factories then it is unnecessary to explicitly set it in the springBoot configuration. Layout factories are only used when no explicit layout is specified.

When spring-boot is applied to your Gradle project a default task named bootRepackage is created automatically. The bootRepackage task depends on Gradle assemble task, and when executed, it tries to find all jar artifacts whose qualifier is empty (i.e. tests and sources jars are automatically skipped).

Due to the fact that bootRepackage finds 'all' created jar artifacts, the order of Gradle task execution is important. Most projects only create a single jar file, so usually this is not an issue; however, if you are planning to create a more complex project setup, with custom Jar and BootRepackage tasks, there are few tweaks to consider.

If you are 'just' creating custom jar files from your project you can simply disable default jar and bootRepackage tasks:

jar.enabled = false
bootRepackage.enabled = false

Another option is to instruct the default bootRepackage task to only work with a default jar task.

bootRepackage.withJarTask = jar

If you have a default project setup where the main jar file is created and repackaged, 'and' you still want to create additional custom jars, you can combine your custom repackage tasks together and use dependsOn so that the bootJars task will run after the default bootRepackage task is executed:

task bootJars
bootJars.dependsOn = [clientBoot1,clientBoot2,clientBoot3]
build.dependsOn(bootJars)

All the above tweaks are usually used to avoid situations where an already created boot jar is repackaged again. Repackaging an existing boot jar will not break anything, but you may find that it includes unnecessary dependencies.

If you are declaring dependencies without versions and you want to publish artifacts to a Maven repository you will need to configure the Maven publication with details of Spring Boot’s dependency management. This can be achieved by configuring it to publish poms that inherit from spring-boot-starter-parent or that import dependency management from spring-boot-dependencies . The exact details of this configuration depend on how you’re using Gradle and how you’re trying to publish the artifacts.

uploadArchives {
    repositories {
        mavenDeployer {
            pom {
                project {
                    parent {
                        groupId "org.springframework.boot"
                        artifactId "spring-boot-starter-parent"
                        version "1.5.2.RELEASE"
}

uploadArchives {
    repositories {
        mavenDeployer {
            pom {
                project {
                    dependencyManagement {
                        dependencies {
                            dependency {
                                groupId "org.springframework.boot"
                                artifactId "spring-boot-dependencies"
                                version "1.5.2.RELEASE"
                                type "pom"
                                scope "import"