Introduction

Questions about "including resources" with the Spring Boot Maven Plugin usually come from two different needs: packaging files into the final jar, or making resource changes visible while running the app from Maven. Those are related, but they are not handled by the same part of the build.

What the Spring Boot Plugin Actually Does

The spring-boot-maven-plugin is mainly responsible for running a Spring Boot app and repackaging the build output into an executable jar or war. It is not the main place where normal classpath resources are selected. Standard resource copying is handled by Maven’s build lifecycle, especially process-resources.

That distinction matters because many developers try to add extra files under the Spring Boot plugin configuration and then wonder why they are missing from the packaged artifact. For packaging, the first place to look is the build.resources section in pom.xml.

Here is a common setup that includes the default resource directory and one additional directory:

1<build>
2  <resources>
3    <resource>
4      <directory>src/main/resources</directory>
5    </resource>
6    <resource>
7      <directory>src/main/config</directory>
8      <includes>
9        <include>**/*.yml</include>
10        <include>**/*.properties</include>
11      </includes>
12    </resource>
13  </resources>
14
15  <plugins>
16    <plugin>
17      <groupId>org.springframework.boot</groupId>
18      <artifactId>spring-boot-maven-plugin</artifactId>
19    </plugin>
20  </plugins>
21</build>

With this configuration, Maven copies those files into target/classes, and the Spring Boot repackaging step picks them up automatically.

Include Resources While Running with Maven

There is a second issue that often gets mixed in: when you run the app with mvn spring-boot:run, you may want edits under src/main/resources to be picked up without a full rebuild. That is where the Spring Boot plugin can help through addResources.

1<plugin>
2  <groupId>org.springframework.boot</groupId>
3  <artifactId>spring-boot-maven-plugin</artifactId>
4  <configuration>
5    <addResources>true</addResources>
6  </configuration>
7</plugin>

When addResources is enabled, the plugin adds resource directories directly to the runtime classpath for spring-boot:run. This is convenient during development because templates, properties, and static assets can update more naturally.

The important limit is that addResources affects the run goal, not the final packaged jar. If you need files to ship inside the artifact, keep the build.resources section correct.

Verifying That Resources Are Available

A simple way to prove that a file is on the classpath is to load it from Spring or from plain Java. This example reads a file named messages/app-banner.txt from the packaged resources:

1import java.io.IOException;
2import java.nio.charset.StandardCharsets;
3import org.springframework.core.io.ClassPathResource;
4
5public class ResourceReader {
6
7    public static String readBanner() throws IOException {
8        ClassPathResource resource =
9            new ClassPathResource("messages/app-banner.txt");
10        return new String(resource.getInputStream().readAllBytes(), StandardCharsets.UTF_8);
11    }
12}

If that code fails with a file-not-found error, check whether the resource is present under target/classes/messages/app-banner.txt after mvn package. That directory tells you what Maven actually copied before Spring Boot repackaged the jar.

Filtering is another common requirement. If you need placeholders to be replaced during the build, configure filtering on the resource entry rather than expecting Spring Boot to do it for you:

1<resource>
2  <directory>src/main/resources</directory>
3  <filtering>true</filtering>
4  <includes>
5    <include>**/*.properties</include>
6  </includes>
7</resource>

Use filtering carefully. It is useful for text files, but it can corrupt binary files if applied too broadly.

Common Pitfalls

One frequent mistake is placing resource include rules inside the Spring Boot plugin and assuming they control packaging. In most cases, resource selection belongs under build.resources.

Another mistake is confusing development-time convenience with packaging behavior. addResources makes spring-boot:run nicer, but it does not fix a missing resource in the built jar.

Filtering can also cause subtle problems. If you enable filtering for every file in src/main/resources, you may break images, fonts, or other binary assets. Limit filtering to known text formats.

Finally, developers sometimes test with filesystem paths such as src/main/resources/file.txt. That works only in certain local setups and fails once the app is packaged. For application code, prefer classpath loading with Spring’s resource abstractions or the class loader.

Summary

• Packaging resources is primarily a Maven build.resources concern.
• The Spring Boot Maven Plugin mainly runs the app and repackages the artifact.
• Use addResources for convenient development-time behavior with spring-boot:run.
• Verify copied files in target/classes when debugging missing resources.
• Apply filtering only to text resources that actually need placeholder replacement.