Introduction

It is common to want values from pom.xml, such as the application version or artifact name, inside Spring Boot configuration files. The usual solution is Maven resource filtering, but it must be configured carefully because Spring Boot also uses placeholder syntax and the two systems can easily collide.

Why Maven Properties Do Not Automatically Appear

Maven properties exist at build time. Spring Boot reads application.properties at application startup. Those are different phases, so a property like ${project.version} in application.properties does nothing unless Maven processes that file during the build.

The basic idea is:

• Maven replaces placeholders while packaging the application
• Spring Boot later reads the already-filtered file from the classpath

Without resource filtering, your packaged file still contains the original placeholder text.

Configuring Resource Filtering

A common and safe approach is to use @...@ placeholders in application.properties. That avoids conflicts with Spring's own ${...} syntax for runtime configuration.

In pom.xml, enable filtering for the resources directory:

1<build>
2  <resources>
3    <resource>
4      <directory>src/main/resources</directory>
5      <filtering>true</filtering>
6    </resource>
7  </resources>
8</build>

Now add values to src/main/resources/application.properties:

app.name=@project.artifactId@
app.version=@project.version@
app.description=@project.description@

During mvn package, Maven replaces those placeholders with values from the project model.

Reading the Filtered Values in Spring Boot

Once the build has filtered the file, Spring Boot can bind those values like any other property.

1package com.example.demo;
2
3import org.springframework.beans.factory.annotation.Value;
4import org.springframework.boot.CommandLineRunner;
5import org.springframework.stereotype.Component;
6
7@Component
8public class AppInfoRunner implements CommandLineRunner {
9
10    @Value("${app.name}")
11    private String appName;
12
13    @Value("${app.version}")
14    private String appVersion;
15
16    @Override
17    public void run(String... args) {
18        System.out.println(appName + " " + appVersion);
19    }
20}

If your pom.xml contains:

<artifactId>demo-service</artifactId>
<version>1.2.3</version>
<description>Sample filtered application</description>

then the packaged application.properties contains real values, not placeholders.

Keeping Build-Time and Runtime Properties Separate

This separation matters because Spring properties often need runtime overrides from environment variables, command-line arguments, or deployment systems.

For example, this is a good mix:

app.version=@project.version@
server.port=${PORT:8080}
spring.datasource.url=${DB_URL:jdbc:h2:mem:testdb}

Here:

• '@project.version@ is resolved by Maven at build time'
• '${PORT:8080} is resolved by Spring at runtime'
• '${DB_URL:...} stays dynamic for each environment'

That distinction keeps your artifact metadata fixed while operational settings stay configurable.

Using Custom Maven Properties

You are not limited to built-in project fields. You can define your own Maven properties in pom.xml and filter them into the application configuration.

1<properties>
2  <java.version>21</java.version>
3  <api.base.path>/api/v1</api.base.path>
4</properties>

Then reference them:

app.api-base-path=@api.base.path@

This is useful for build metadata, generated file paths, or values shared across plugins and resources.

Common Pitfalls

The most common mistake is using ${project.version} inside application.properties without enabling Maven filtering. Spring tries to resolve that at runtime and usually fails because no such Spring property exists.

Another mistake is enabling filtering for all resource files without thinking about side effects. If a YAML or properties file contains Spring placeholders like ${HOME} or ${PORT}, Maven may try to interpret them too. Using @...@ for Maven placeholders avoids most of that confusion.

A third issue is editing application.properties and then launching from an IDE without rebuilding. Maven filtering happens during the build, so if you run stale compiled resources, you may still see old values.

Finally, do not put secrets in pom.xml just because filtering works. Build metadata is not secret management. Keep credentials in environment-specific runtime configuration.

Summary

• Maven properties are build-time values, while Spring Boot properties are read at runtime.
• Enable resource filtering if you want pom.xml values inside application.properties.
• Prefer @...@ placeholders for Maven to avoid conflicts with Spring ${...} placeholders.
• Use filtered values for fixed metadata such as app name and version.
• Keep operational settings and secrets in runtime configuration, not in the Maven project file.