• For example mine is 192.168.99.100, I'm using this instead of 192.168.59.103 that's in the example., If you'd like to use the bootRun command make sure you are running it against the build.gradle in the core module like this (the properties file only works with an absolute path for me).
• Multi-Project/Module example with Gradle, Kotlin and Spring with Kotlin DSL - mrclrchtr/gradle-kotlin-spring.

docker-compose.yml

$ gradle tasks Build $ gradle assemble or $ gradle compileJava Test $ gradle test Run $ gradle bootRun Deploy Nexus /.gradle/gradle.properties: nexusUsername = admin nexusPassword = admin123 $ gradle uploadArchives Docker $ gradle dockerPushImage.

Gradle 4.9 introduced the -args parameter to bootRun, which I can use easily from the command-line, but how do I use this from a Run/Debug configuration in Intellij 2018? With a Gradle build set to run the bootRun task on my project in Intellij, I've tried the following arguments in the Run/Debug Configurations screen without any success:-args 'foo'. Every Gradle build is made up of one or more projects. What a project represents depends on what it is that you are doing with Gradle. For example, a project might represent a library JAR or a web application. It might represent a distribution ZIP assembled from the JARs produced by other projects.

Set accounts password

Users

SQLPLUS

The accounts to connect to oracle via sqlplus are:

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

or

Test

Run

Nexus

~/.gradle/gradle.properties:

Docker

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

Gradle Boot Run Example Key

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

Gradle Bootrun Debug

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

Gradlew Bootrun

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

Gradle Task Bootrun

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