Exchangefox804

Gradle's bootRun task supports passing -args='-spring.profiles.active=dev' with the Spring Boot Gradle plugin. There's an alternative too. All we need is a task that would set the property, before spring boot app starts. Here's an example from build.gradle.kts. For showcasing purposes, I’ve added some examples about how to add parameters, send 200 responses with JSON objects and send errors with custom messages. To test that our first web service is working, we first need to build it into our local machine, we can do that by running the gradle command bootRun. This is the recommended project structure for starting any Gradle project. The build init plugin also generates skeleton projects that follow this structure - a root project with a single subproject. Note that the root project does not have a Gradle build file, only a settings file that defines the.

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:

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:

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:

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:

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

bootRun task

The task graph for the bootRun task is this:

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:

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:

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:

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:

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:

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:

Which now returns:

Spring Boot magicexplained
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:

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

Video

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

Related Posts

docker-compose.yml

Set accounts password

Users

SQLPLUS

The accounts to connect to oracle via sqlplus are:

Gradle Boot Run Example Iso

Enteprise Management

To enable Enteprise Management for container ORCLPDB1:

Connect to https://oracle:5502/em/ username = sys, password=oracle and AS SYSDBA

Create user and rights for json insert via java/soda

Create a tablespace oracle, create a user oracle with password oracle grant rights to use soda:

Soda

Check inserted data

Tasks

Build

Gradle Bootrun Arguments

or

Test

Gradle Bootrun Stop

Run

Gradle Boot Run Example Sentences

Nexus

~/.gradle/gradle.properties:

Gradle Boot Run Example Sheet

Docker