skip to content

How do <build><filters> files relate to resource filtering, and when would you use them instead of <properties>?

level: seniorimportance: should knowfreq 35%

answer

  1. <filters> = external .properties source
  2. for resource filtering only
  3. pair with profiles per env
  4. later filter overrides earlier
  5. -D / <properties> beat filter files

basics

~10 s

<filters> points to external .properties files whose key=value pairs become available during resource filtering, alongside pom properties. You use them to keep environment-specific values out of the pom, often selected per Maven profile.

solid answer

~30 s

Under <build> you can list <filters><filter>path/to/file.properties</filter></filters>. The resources plugin loads those files as additional property sources when filtering resources. They are useful when you want environment-specific config (dev/qa/prod URLs, credentials placeholders) kept in separate files rather than inline in the pom, and you typically combine them with profiles so each profile activates a different filter file. Precedence matters: command-line -D system properties and pom <properties> generally override values from filter files, and later filters override earlier ones. A common pattern is a profile that sets <filters> to filters/${env}.properties so the same resource templates render per environment.

code

xml · 11 lines
xml
<build>
  <filters>
    <filter>src/main/filters/${env}.properties</filter>
  </filters>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
</build>

go deeper

for a junior

Aware that external .properties files can supply filtering values.

for a middle

Knows the <filters> syntax and that they feed resource filtering only.

for a senior

Combines filters with profiles for per-environment builds and reasons about precedence/layering.

for a principal

Designs an env-config strategy (filters + profiles + secret references) that is reproducible and avoids secrets-in-pom.

## What `<filters>` are A **filter file** is an external `.properties` file (key=value lines) that Maven loads as an *extra* source of property values *for resource filtering only*. You register them in the build section: ```xml <build> <filters> <filter>src/main/filters/${env}.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build> ``` With `src/main/filters/prod.properties`: ```properties db.url=jdbc:postgresql://prod-host/app feature.flag=true ``` any `${db.url}` token in a filtered resource resolves from that file. ## `<filters>` vs `<properties>` - `<properties>` live inside the pom — good for versions and values that belong with the build definition. - `<filters>` externalize values into separate files — good for **environment-specific** config you want to swap without touching the pom, or keep in a different location/secret store reference. ## Profiles make them dynamic The real power is pairing filters with **profiles**. Each profile sets a different filter file (or a property `${env}` used in the filter path), so `mvn package -Pprod` filters resources with prod values and `-Pdev` with dev values — from the *same* resource templates. ```xml <profiles> <profile> <id>prod</id> <properties><env>prod</env></properties> </profile> </profiles> ``` ## Precedence When the same key exists in multiple places, the effective order is roughly: command-line `-D` system properties and pom `<properties>` take precedence over filter-file values, and among multiple `<filter>` entries, **later files override earlier ones**. So you can layer a base filter file plus an environment override. ## Scope limitation Filter files only feed **resource filtering**. They do not become usable as `${...}` inside the pom's own elements (use `<properties>` for that).

  • Can a value defined in a filter file be referenced as ${...} elsewhere in the pom?
    No. Filter files only feed resource filtering. To use a value inside pom elements, define it under <properties>.
  • If the same key is in a filter file and -D on the command line, which wins?
    The command-line -D system property wins over the filter file value.

saying these in an interview costs you the question

  • Claiming filter-file keys are usable as ${...} inside the pom itself.
  • Saying filters always override pom <properties> (it's the other way for that conflict).

context

resolving links…