Profile-Specific Properties Files with Maven

Beginner·3 min read·

Fast recall

Quick revision

Core answer

A Maven profile can select a resource directory or provide values used by Maven resource filtering, so mvn package -P... can create a profile-specific artifact. Enable filtering explicitly and use the delimiter expected by the Spring Boot parent. Do not bake passwords or other secrets into the artifact; for most application environments, build once and supply Spring configuration at runtime.

Interview Answer3 min

Maven resource filtering lets you inject profile-specific values into property files during the build. Here's how it works. In my application.properties file, I'd write placeholders using Maven property syntax, like spring.datasource.url equals ${db.url}. Then in my pom.xml, I'd define Maven profiles that set different values for db.url. The dev profile might set it to jdbc:h2:mem:devdb, while the prod profile sets it to the actual production PostgreSQL URL. The key step is enabling filtering in the build section — I'd add a resource configuration with filtering set to true. Now when I run mvn package -Pprod, Maven's resource plugin copies application.properties into the JAR but replaces all the placeholders with production values. The packaged JAR contains the final substituted values, not the placeholders. One critical mistake freshers make is hardcoding secrets in these profiles. Like defining db.password equals prod123 directly in the pom.xml and committing it. That's a security nightmare because the password ends up in Git history and baked into the JAR. The right approach is using environment variable syntax, like ${env.DB_PASSWORD}, so Maven pulls the secret from an environment variable during the build. Even better, don't use Maven filtering for secrets at all. Use Spring's externalized configuration to inject secrets at runtime via environment variables or a secrets vault. That way, secrets never touch your codebase or artifacts. Another point: Maven resource filtering creates environment-specific JARs, which violates the build once, deploy everywhere principle. You're building dev.jar and prod.jar separately, so you're not testing the exact artifact you deploy. Modern best practice is to build one JAR and use Spring profiles or environment variables to change behavior at runtime. Maven resource filtering is useful for non-sensitive config like feature flags or API timeouts, but for critical config like database credentials, inject at runtime.

Interview-ready guide

Interview answer

Maven resource filtering lets you inject profile-specific values into property files during the build.

Here's how it works. url}. url.

The dev profile might set it to jdbc:h2:mem:devdb, while the prod profile sets it to the actual production PostgreSQL URL. The key step is enabling filtering in the build section — I'd add a resource configuration with filtering set to true. properties into the JAR but replaces all the placeholders with production values.

The packaged JAR contains the final substituted values, not the placeholders. One critical mistake freshers make is hardcoding secrets in these profiles. xml and committing it.

That's a security nightmare because the password ends up in Git history and baked into the JAR. DB_PASSWORD}, so Maven pulls the secret from an environment variable during the build. Even better, don't use Maven filtering for secrets at all.

Use Spring's externalized configuration to inject secrets at runtime via environment variables or a secrets vault. That way, secrets never touch your codebase or artifacts. Another point: Maven resource filtering creates environment-specific JARs, which violates the build once, deploy everywhere principle.

jar separately, so you're not testing the exact artifact you deploy. Modern best practice is to build one JAR and use Spring profiles or environment variables to change behavior at runtime. Maven resource filtering is useful for non-sensitive config like feature flags or API timeouts, but for critical config like database credentials, inject at runtime.

03 · Deep dive