Loading External Application Properties in the Gradle bootRun Task

Loading External Application Properties in the Gradle bootRun Task

Table Of Contents

The Spring Boot gradle plugin provides the bootRun task that allows a developer to start the application in a “developer mode” without first building a JAR file and then starting this JAR file. Thus, it’s a quick way to test the latest changes you made to the codebase.

Sadly, most applications cannot be started or would not work correctly without specifying a couple configuration parameters. Spring Boot supports such parameters with it’s application.properties file. The parameters in this file are automatically read when the application is started from a JAR and passed to the application.

The bootRun task also allows to define such properties. The common way of doing this is like this in the build.gradle file:

bootRun {
  jvmArgs =
    [
      "-DmyApp.myParam1=value1",
      "-DmyApp.myParam2=value2"
    ]
}

However, if your are working at the codebase together with other developers, each developer may want to test different use cases and needs different configuration values. She would have to edit the build.gradle each time. And each time she checks in changes to the codebase, she has to check if the build.gradle file should really be checked in. Which is not what we want.

The solution to this problem is a specific properties file for each developer’s local environment that is not checked into the VCS. Let’s call it local.application.properties. In this file, put your applications configuration parameters just as you would in a real application.properties file.

To make the bootRun task load these properties, add the following snippet to your build.gradle:

def Properties localBootRunProperties() {
    Properties p = new Properties();
    p.load(new FileInputStream(
      file(project.projectDir).absolutePath + "/local.application.properties"))
    return p;
}

Then, in your bootRun task, fill the systemProperties attribute as follows:

bootRun {
  doFirst {
    bootRun.systemProperties = localBootRunProperties()
  }
}

The call to localBootRunProperties() is put into the doFirst closure so that it gets executed only when the task itself is executed. Otherwise event all other tasks would fail with a FileNotFoundException if the properties file is not found instead of only the bootRun task.

Further Reading

Written By:

Tom Hombergs

Written By:

Tom Hombergs

As a professional software engineer, consultant, architect, general problem solver, I've been practicing the software craft for more than fifteen years and I'm still learning something new every day. I love sharing the things I learned, so you (and future me) can get a head start. That's why I founded reflectoring.io.

Recent Posts

Understanding Socket.IO: Building a simple real-time chat app with Node.js and Socket.IO

Traditional web applications primarily used the HTTP request-response model, where clients sent requests to servers, and servers responded with data. However, implementing real-time features like live chat, notifications, collaborative tools, etc, was challenging.

Read more

Spring Basics

At its core, Spring is a Dependency Injection framework. Although it now offers a variety of other features that simplify developers' lives, most of these are built on top of the Dependency Injection framework.

Read more

Spring Boot Basics

Spring Boot builds on top of the Spring Framework and provides a wealth of additional features and integrations. To simplify somewhat, one could say that the Spring Framework focuses on functions related to the application context, while Spring Boot provides functions that are needed in many applications running in production or that simplify developer life.

Read more