Add Build Properties to a Spring Boot Application

1. Introduction

Usually, our project’s build configuration contains quite a lot of information about our application. Some of this information might be needed in the application itself. So, rather than hard-code this information, we can use it from the existing build configuration.

In this tutorial, we’ll see how to use information from the project’s build configuration in a Spring Boot application.

2. The Build Information

Let’s say we want to display the application description and version on our website’s home page.

Usually, this information is present in pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <artifactId>spring-boot</artifactId>
    <name>spring-boot</name>
    <packaging>war</packaging>
    <description>This is simple boot application for Spring boot actuator test</description>
    <version>0.0.1-SNAPSHOT</version>
...
</project>

3. Referencing the Information in the Application Properties File

Now, to use the above information in our application, we’ll have to first reference it in one of our application properties files:

[email protected]@
[email protected]@

Here, we’ve used the value of the build property project.description to set the application property application-description. Similarly, application-version is set using project.version.

The most significant bit here is the use of the @ character around the property name. This tells Spring to expand the named property from the Maven project.

Now, when we build our project, these properties will be replaced with their values from pom.xml.

This expansion is also referred to as resource filtering. It’s worth noting that this kind of filtering is only applied to the production configuration. Consequently, we cannot use the build properties in the files under src/test/resources.

Another thing to note is that if we use the addResources flag, the spring-boot:run goal adds src/main/resources directly to the classpath. Although this is useful for hot reloading purposes, it circumvents resource filtering and, consequently, this feature, too.

Now, the above property expansion works out-of-the-box only if we use spring-boot-starter-parent.

3.1. Expanding Properties Without spring-boot-starter-parent

Let’s see how we can enable this feature without using the spring-boot-starter-parent dependency.

First, we have to enable resource filtering inside the <build/> element in our pom.xml:

<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
    </resource>
</resources>

Here, we’ve enabled resource filtering under src/main/resources only.

Then, we can add the delimiter configuration for the maven-resources-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <delimiters>
            <delimiter>@</delimiter>
        </delimiters>
        <useDefaultDelimiters>false</useDefaultDelimiters>
    </configuration>
</plugin>

Note that we’ve specified the useDefaultDelimiters property as false. This ensures that the standard Spring placeholders such as ${placeholder} are not expanded by the build.

4. Using the Build Information in YAML Files

If we’re using YAML to store application properties, we might not be able to use @ to specify the build properties. This is because @ is a reserved character in YAML.

But, we can overcome this by either configuring a different delimiter in maven-resources-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <delimiters>
            <delimiter>^</delimiter>
        </delimiters>
        <useDefaultDelimiters>false</useDefaultDelimiters>
    </configuration>
</plugin>

Or, simply by overriding the resource.delimiter property in the properties block of our pom.xml:

<properties>
    <resource.delimiter>^</resource.delimiter>
</properties>

Then, we can use ^ in our YAML file:

application-description: ^project.description^
application-version: ^project.version^

5. Using BuildProperties Bean

In this section, we’ll learn how to retrieve the build information using the BuildProperties bean in a Spring Boot project.

5.1. Maven Setup

In a Spring Boot project, we add the build-info goal to the spring-boot-maven-plugin within the project’s pom.xml file:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
                <execution>
                    <id>build-info</id>
                    <goals>
                        <goal>build-info</goal>
                    </goals>
                    <configuration>
                        <additionalProperties>
                            <java.version>${java.version}</java.version>
                            <description>${project.description}</description>
                            <custom.value>123</custom.value>
                        </additionalProperties>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
<build>

We must note that the plugin allows us to define custom properties within the additionalProperties tag. Further, the values for the custom properties could be either constant or derived from other variables.

Now, we’re ready to build our project and inspect the build-info.properties file under the target/classes/META-INFO directory:

$ cat target/classes/META-INF/build-info.properties 
build.artifact=spring-boot-properties
build.custom.value=123
build.description=Spring Boot Properties Module
build.group=com.baeldung.spring-boot-modules
build.java.version=11
build.name=spring-boot-properties
build.time=2023-04-08T04\:29\:28.905Z
build.version=0.0.1-SNAPSHOT

As expected, all the build information is now available within the application.

5.2. Accessing Build Properties

To access the build information, let’s use the BuildProperties bean within our application code:

@Autowired
private BuildProperties buildProperties;

Next, let’s go ahead and access the default build properties such as artifact, group, and version:

@Test
void givenBuildPropertiesBean_WhenFetchDefaultBuildProperties_ThenGetValidValues() {
    Assertions.assertEquals("spring-boot-properties", buildProperties.getArtifact());
    Assertions.assertEquals("com.baeldung.spring-boot-modules", buildProperties.getGroup());
    Assertions.assertEquals("0.0.1-SNAPSHOT", buildProperties.getVersion());
}

Finally, let’s also validate the additional build properties that we configured in the plugin:

@Test
void givenBuildPropertiesBean_WhenFetchCustomBuildProprties_ThenGetValidValues() {
    Assertions.assertEquals("123", buildProperties.get("custom.value"));
    Assertions.assertNotNull(buildProperties.get("java.version"));
    Assertions.assertEquals("Spring Boot Properties Module", buildProperties.get("description"));
}

Great! It looks like we’ve got this right.

5.3. Gradle Setup

If we’re using Gradle to build our project, then we can use the build.gradle file for configuring the buildInfo plugin:

springBoot {
    buildInfo {
        properties {
            additional = [
                'description': project.getDescription(),
                'java.version': JavaVersion.current(),
                'custom.value': 123,
            ]
        }
    }
}

Further, we’ll find the build-info.properties under the build/resources/main/META-INFO directory for our Gradle project:

$ cat build/resources/main/META-INF/build-info.properties
build.artifact=spring-boot-properties
build.custom.value=123
build.description=Spring Boot Properties Module
build.group=com.baeldung.spring-boot-modules
build.java.version=11
build.name=spring-boot-properties
build.time=2023-04-08T05\:14\:12.283459Z
build.version=0.0.1-SNAPSHOT

That’s it! We don’t need any change in the application code.

6. Conclusion

In this article, we saw how we could use Maven project information in our application. This can help us to avoid hardcoding the information that’s already present in the project build configuration in our application properties files.