Understanding Maven Resource Filtering and Variable Substitution in Spring Boot Projects

When creating a Spring Boot project, the default parent POM defines common settings such as JDK version, encoding, dependency versions, and plugin versions, and includes a <resources>... configuration that controls which files are packaged and whether they participate in compilation.

The first <resource> entry points to ${basedir}/src/main/resources , includes application*.yml , application*.yaml , and application*.properties , and sets filtering to true , meaning variables defined in pom.xml can be referenced inside these files and they will be processed during compilation.

The second <resource> entry uses the same directory but lists the same three file patterns under <excludes> and does not enable filtering, so all other resources are simply copied into the final artifact without compilation.

In summary, every file under resources is packaged, but the three listed configuration files are also filtered and compiled.

The parent POM also defines properties such as:

<properties>
  <java.version>17</java.version>
  <resource.delimiter>@</resource.delimiter>
  <maven.compiler.source>${java.version}</maven.compiler.source>
  <maven.compiler.target>${java.version}</maven.compiler.target>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

Setting <resource.delimiter>@</resource.delimiter> changes the placeholder delimiter from ${...} to @...@ , allowing YAML or properties files to reference Maven variables using the @variable@ syntax.

Example YAML using the new delimiter:

app:
  java:
    version: @java.version@

After building the project, the placeholder is replaced with the actual value (e.g., 17 ).

By default, only application*.yaml , application*.yml , and application*.properties support variable substitution; other file types require explicit filtering configuration.

To enable filtering for .txt files, add the following to pom.xml :

<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <includes>
        <include>**/*.txt</include>
      </includes>
      <filtering>true</filtering>
    </resource>
  </resources>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

With this configuration, any .txt file under resources can use @variable@ placeholders that Maven will replace during the build.

Multi‑environment profiles can be defined in the POM:

<profiles>
  <profile>
    <id>dev</id>
    <properties>
      <package.environment>dev</package.environment>
    </properties>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
  </profile>
  <profile>
    <id>prod</id>
    <properties>
      <package.environment>prod</package.environment>
    </properties>
  </profile>
  <profile>
    <id>test</id>
    <properties>
      <package.environment>test</package.environment>
    </properties>
  </profile>
</profiles>

Using the placeholder @package.environment@ in application.yaml allows the active profile to be selected without hard‑coding:

spring:
  profiles:
    active: @package.environment@

When building, the desired profile can be activated with Maven, e.g., mvn package -Ptest , which results in application.yaml containing active: test . IDEs such as IntelliJ IDEA also provide UI controls to select a profile before packaging.

This knowledge helps developers understand how Maven resource filtering works, how to customize placeholder delimiters, and how to manage environment‑specific configurations in Spring Boot applications.