Unleashing the Spring Boot Gradle plugin

Unleashing the Spring Boot Gradle plugin

Last Updated on March 18, 2021

1. Introduction

Spring Boot is a framework to build Java applications with minimal boilerplate code required, whereas Gradle is a highly configurable build automation tool.

Using Gradle to build your Spring Boot application is a good approach, but the process is made infinitely easier using the Spring Boot Gradle plugin to provide build functionality specific to Spring Boot.

In this article, we’ll explore the most common uses case to get up and running with the Spring Boot Gradle plugin, as well as how to customise it to meet your specific requirements.

2. Applying the plugin

Simply add the latest version of the Spring Boot Gradle plugin to the plugins declaration in your build.gradle file, like this:

plugins {
    id 'org.springframework.boot' version '2.2.6.RELEASE'

Note that the version of the plugin applied here corresponds directly to the version of Spring Boot that you’re targeting.

This on its own doesn’t add anything to your build. Instead, the Spring Boot Gradle plugin is reactive, meaning that its behaviour changes depending on what other plugins you have applied.

Reacting to the java plugin

Let’s also add the java plugin. This core Gradle plugin provides Java compilation and testing capabilities to your project. Chances are, if you already have a Spring Boot project, you’ll have the java plugin. It’s applied like this:

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.2.6.RELEASE'

Now things get a bit more interesting. ✅ The Spring Boot plugin reacts to the java plugin by adding:

  • a bootJar task which builds a fat jar containing everything required in order to run your application standalone
  • a bootRun task which starts your application
  • some configuration and wiring, including
    • disabling the jar task, as it’s replaced by bootJar
    • hooking up the bootJar task to run whenever the Java plugin’s assemble task runs

bootJar task

Our task graph for the assemble task now looks like this:

+--- :bootJar
|    \--- :classes
|         +--- :compileJava
|         \--- :processResources

Task graphs
In Gradle tasks are linked together in a graph structure. If we have two tasks, A and B, task A can be configured to depend on task B. This means that whenever we run task A, task B will be run first. You can view the task graph using the task-tree plugin.

This means that whenever you run ./gradlew assemble (or build) the fat jar for your application will get created with the bootJar task:

Run Gradle with --info to see full output like this

The fat jar gets output to build/libs/<project-name>-<project-version>.jar.

bootRun task

The task graph for the bootRun task is this:

\--- :classes
     +--- :compileJava
     \--- :processResources

If we grun ./gradlew bootRun the plugin will look for a class with a public static void main(String[] args) method. In a Spring Boot application this is typically a class which is annotated with @SpringBootApplication, which when run starts the application.

We’ll see output like this, telling us that the application has started successfully:

If you have multiple classes with public static void main(String[] args) methods, you can configure which one to use like this:

bootRun {
    main = 'com.tomgregory.ExampleApplication'

Reacting to the war plugin

The war plugin extends the java plugin. Rather than generating the jar file, you’ve guess it, it generates a war file instead.

The Spring Boot Gradle plugin reacts to this plugin by creating the bootWar task, which generates an executable fat war file similar to the jar.

bootWar task

The task graph for the bootWar task looks like this:

\--- :classes
     +--- :bootBuildInfo
     +--- :compileJava
     \--- :processResources

If we run ./gradlew assemble now the fat war will get created through the bootWar task:

The fat war gets output to build/libs/<project-name>-<project-version>.war.

war vs. jar
The contents of these two files are very similar. However, they differ in structure since the war file contains a WEB-INF directory and the jar a BOOT-INF. They are both executable with java -jar <file-name>. But, with some small changes to your configuration the war file can also be deployed to a standalone Tomcat instance.

3. Declaring Spring Boot dependencies without the version number

If you also apply the io.spring.dependency-management plugin then the Spring Boot Gradle plugin will import the spring-boot-dependencies BOM (or the bill of materials) for whatever version of Spring you’re targeting:

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.2.6.RELEASE'
    id 'io.spring.dependency-management' version "1.0.9.RELEASE"

This means that the plugin will know what versions of Spring Boot dependencies to bring in, so you don’t have to declare the versions yourself. It derives the Spring Boot version from the version of the Spring Boot plugin that you’ve applied, which in this case will be 2.2.6.RELEASE.

Dependencies can then be declared in short form like this:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'

4. Adding build info

Spring Boot actuator endpoints provide a way to monitor your application. The /actuator/info endpoint, according to the docs:

Displays arbitrary application info.

By default if you hit localhost:8080/actuator/info you’ll see this:


Not much fun to be had here. 🥱 Let’s fix this by getting the Spring Boot Gradle plugin to include build information by adding this configuration to build.gradle:

springBoot {

Now the same URL returns this:


You can see that the plugin has chosen sensible defaults for all these fields. Any of them can be overridden using the properties configuration, like this:

springBoot {
    buildInfo {
        properties {
            name = 'Amazing application name'

Which now returns:

      "name":"Amazing application name",

Spring Boot magic explained
The Spring Boot Gradle plugin generates a build/resources/main/META-INF/build-info.properties file which Spring Boot loads onto the info endpoint automatically

5. Publishing

Eventually once you’re happy with your jar or war file, you’ll want to publish it. The maven-publish plugin allows you to publish Gradle built artifacts to a Maven repository.

We can use outputs from the bootJar (or bootWar) task like this, by passing the task to the artifact method:

publishing {
    publications {
        bootJava(MavenPublication) {
            artifact bootJar
    repositories {
        maven {
            url 'http://localhost:8081/repository/snapshots'
            credentials {
                username property('mavenUser')
                password property('mavenPassword')

Now we can run ./gradlew publish -PmavenUser=<user> -PmavenPassword=<password> and see that our jar file has been published:

Get your own Maven repository
If you want to try this out yourself, see the article How To Secure Your Gradle Credentials In Jenkins where we run through how to setup a local Maven repository using Apache Archiva

6. Resources

GitHub repository

Check out the accompanying repository which includes a simple Spring Boot project for you to try out the ideas in this article, without writing any code.

Official documentation

See Spring Boot’s guide to this plugin


If you prefer to learn in video format, check out the accompanying video to this post on the Tom Gregory Tech YouTube channel.

Get going with Gradle course
Gradle icon

Want to learn more about Gradle?
Check out the full selection of Gradle tutorials.

Unleashing the Spring Boot Gradle plugin

Leave a Reply

Your email address will not be published.

Scroll to top


Getting started with Gradle just got A LOT easier!

Get Going with Gradle is the fastest way to a working knowledge of Gradle.

✅ Work effectively in basic Gradle projects
✅ Know how to setup Java projects in Gradle
✅ Understand the Gradle fundamentals

And it's yours today for FREE!

Where shall I send your access details?