Introduction

Using Maven properties inside application.yml is really a build-time resource-filtering question, not a Spring Boot runtime feature by itself. The key is to separate two kinds of placeholders: values Maven should expand during the build and values Spring should resolve later when the application starts.

Understand Build-Time Versus Runtime Expansion

These two placeholder systems look similar but serve different purposes:

• Maven properties are expanded while the project is built
• Spring placeholders are resolved when the application runs

That distinction matters because careless filtering can accidentally replace Spring expressions that were supposed to stay dynamic.

A Typical Build-Time Version Example

Suppose you want the application version from pom.xml inside YAML:

1info:
2  app:
3    name: "@project.name@"
4    version: "@project.version@"

Those @...@ tokens are intended for Maven resource filtering. After the build, the generated resource file contains the real values.

Using @...@ instead of ${...} is helpful because Spring already uses ${...} for runtime property placeholders. Keeping the delimiters different avoids ambiguous behavior.

Enable Resource Filtering in Maven

In pom.xml, enable filtering for resources:

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

Once filtering is enabled, Maven replaces tokens such as @project.version@ while copying resources into the build output.

If your project uses Spring placeholders heavily, be deliberate about delimiters so Maven does not try to expand values meant for Spring.

Keep Spring Runtime Placeholders Intact

You can still use normal Spring placeholders in the same YAML file:

app:
  build-version: "@project.version@"
  external-url: "${APP_EXTERNAL_URL:https://localhost:8080}"

Here:

• '@project.version@ is resolved at build time by Maven'
• '${APP_EXTERNAL_URL:...} is resolved at runtime by Spring'

That separation is usually the cleanest approach.

Bind the Result Like Any Other Spring Property

Once the application starts, Spring just sees the filtered YAML as ordinary configuration:

1import org.springframework.boot.context.properties.ConfigurationProperties;
2import org.springframework.stereotype.Component;
3
4@Component
5@ConfigurationProperties(prefix = "app")
6public class AppInfoProperties {
7    private String buildVersion;
8    private String externalUrl;
9
10    public String getBuildVersion() { return buildVersion; }
11    public void setBuildVersion(String buildVersion) { this.buildVersion = buildVersion; }
12
13    public String getExternalUrl() { return externalUrl; }
14    public void setExternalUrl(String externalUrl) { this.externalUrl = externalUrl; }
15}

From Spring Boot’s perspective, there is nothing special about these values anymore. Maven already did its part before the app launched.

Consider Build Info for Metadata

If the goal is specifically application metadata such as version, artifact, and group, another option is to generate build information instead of filtering YAML manually. That can be cleaner when you want standardized build metadata rather than general-purpose config interpolation.

Manual filtering is still fine when the build property truly belongs in configuration, but not every version value has to be copied into application.yml.

Common Pitfalls

• Expecting Spring Boot to resolve Maven properties automatically at runtime without Maven resource filtering.
• Using ${project.version} directly and colliding with Spring’s own ${...} placeholder syntax.
• Enabling aggressive filtering and accidentally replacing placeholders that Spring was supposed to handle later.
• Putting secrets into Maven-filtered resources when they should come from environment-specific runtime sources instead.
• Forgetting that filtered YAML values become fixed at build time, not deployment time.

Summary

• Maven properties in application.yml are handled during the build, not by Spring Boot at runtime.
• Use resource filtering and a distinct delimiter such as @project.version@ for build-time expansion.
• Keep Spring runtime placeholders such as ${APP_EXTERNAL_URL} separate from Maven tokens.
• Treat the filtered YAML as ordinary Spring configuration once the application starts.
• Choose build metadata or filtered YAML based on whether the value is really configuration or just artifact metadata.
• Be explicit about which tool owns each placeholder so configuration stays predictable.