1. Introduction
The Spring Boot Gradle Plugin provides Spring Boot support in Gradle. It allows us to package executable JAR or war archives, run Spring Boot applications, and use the dependency management provided by spring-boot-dependencies. Spring Boot 3 Gradle plugin requires Gradle 7.x (7.5 or later) or 8.x and can be used with Gradle’s configuration cache.
In this tutorial, we’re going to learn about Spring Boot 3 Gradle plugin task configurations. There are several gradle tasks available in the Spring Boot 3 Gradle plugin. We’ll use a simple Spring Boot app to demonstrate configuring some tasks. We’ll not add any security or data features to our Spring Boot app for demo purposes. Without further ado, let’s now dive into defining and configuring the tasks in more detail.
In the Spring Boot 3 Gradle plugin, the Gradle tasks have been improved over prior versions. Some common Gradle tasks are bootJar, bootWar, bootRun, and bootBuildImage. Let’s dive into bootJar and see how to configure the bootJar task.
To configure the bootJar task, we have to add a bootJar configuration block to our build.gradle file:
tasks.named("bootJar") {
launchScript{
enabled = true
}
enabled = true
archiveFileName = "bael-6094.${archiveExtension.get()}"
}
This configuration block sets several options for the bootJar task.
The property launchScript generates a launch script packaged inside the resulting JAR. This allows for running the JAR like any other command. For example, without explicitly using java -jar <jarname> we’ll be able to use jarname or ./jarname to run the JAR. To disable the bootjar task, we set the property enabled to false. It’s set to true by default.
We can define the output JAR name using the archiveFileName property. Now, we’re all set to run the bootJar task:
gradlew bootJar
This generates a fully executable JAR in the build/libs folder. The JAR name, in our case, will be bael-6094.jar.
3. Layered JAR Generation
The Spring Boot Gradle Plugin provides support for building layered JARs. This helps to reduce memory usage and promote separation of concerns.
Let’s configure the bootJar task to use a layered architecture. We’re dividing our JAR into two layers, an application and a springBoot layer:
bootJar {
layered {
enabled = true
application {
layer = 'application'
dependencies {
// Add any dependencies that should be included in the application layer
}
}
springBoot {
layer = 'spring-boot'
}
}
}
In this example, the layered feature is enabled, and two layers are defined: the application layer and the spring-boot layer. The application layer contains the application code and any specified dependencies, while the spring-boot layer contains the Spring Boot framework and its dependencies.
Next, let’s build our Spring Boot application using the bootJar task:
./gradlew bootJar
This will create a layered JAR file in the build/libs directory named {projectName}-{projectVersion}-layers.jar.
We get faster startup times and lower memory usage as we separate the application code from the Spring Boot framework code in our layered architecture. Moreover, as in our layered JAR file, we have separate layers for the application and the framework. Therefore, we can share the framework layer across multiple applications. This results in the reduction of code duplication and resources.
4. Configure the bootBuildImage Task
Let’s now use the task bootBuildImage to build our Docker image. The new plugin uses the Cloud Native Buildpacks (CNB) to create an OCI image.
The task bootBuildImage requires access to a docker daemon. It’ll communicate with a Docker daemon over a local connection by default. This works with Docker Engine on all supported platforms without any specific configuration. We can change defaults using environment variables like DOCKER_HOST, DOCKER_TLS_VERIFY, DOCKER_CERT_PATH, and so on. Also, we have the option to configure different properties using the plugin.
Let’s add a typical bootBuildImage task with custom configurations in our build.gradle:
tasks.named("bootBuildImage") {
imageName = 'bael-6094:latest'
}
Next, let’s run the bootBuildImage command:
gradlew.bat bootBuildImage
Let’s ensure our docker service is up and running on our operating system. Docker is available for all the major operating systems, whether it’s Windows, Linux, or macOS. As a result of running the bootBuildImage task, we get an image in our Docker environment. Let’s list the available Docker images in our local environment to verify our newly built image:
docker images
Now, we’re ready to run our container:
docker run -p 8080:8080 bael-6094:latest
The -p 8080:8080 maps our host port 8080 to container port 8080. By default, Spring Boot runs our app on port 8080 inside the container, and the container exposes it for external mapping. There are several other configuration options available in the bootBuildImage task that we can use for different features.
Let’s now navigate to http://localhost:8080/hello in our browser to verify the output.
5. Conclusion
In this article, we’ve covered some Spring Boot 3 Gradle plugin tasks. The tasks have many improvements over the previous versions.
The code backing this article is available on GitHub. Once you're
logged in as a Baeldung Pro Member, start learning and coding on the project.
