In this section, we'll see how to use references to various types of properties in our POMs and how to use them to perform replacements in our project resources. This feature is called resource filtering.
Maven properties are referenced using the ${property-name} syntax. They can be used as follows:
- Anywhere in the POM
- In all the project resources under
/src/main/resources(and/or under any other resource directories defined in our POM)
We have to distinguish between implicit and user-defined properties. The implicit properties are as follows:
- Project properties: We can use the
${project.*}syntax to reference the value of all elements of our effective POM. For example,${project.groupId}and${project.build.directory}refer to the<project><groupId>and<project> <build><directory>elements of our (effective) POM, respectively. Of course, we can only specify properties that are uniquely determined by their path. In other words, we cannot reference a<dependency>or<plugin>element. - Settings properties: These are analogous to the project properties, but they refer to the Maven settings files through the
${settings.*}syntax. - Environment properties: We can refer to the environment variables through the
${env.<variable-name>}syntax. For example, we can reference theJAVA_HOMEorPATHvariable using placeholders such as${env.JAVA_HOME}and${env.PATH}. - System properties: We can reference all the properties accessible via
System.getProperties()by the Maven Java process. Some examples are${os.name}and${line.separator}.
In addition to the implicit properties, we can define our arbitrary user-defined properties in the <properties> element of our POM, as follows:
<project>
[...]
<properties>
<my.property>myValue</my.property>
<other.property>Other value</other.property>
<logback.version>1.0.7</logback.version>
</properties>
[...]
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
</dependencies>
</project>This way, we can put in evidence and factorize some particular values that are used in multiple places in our POMs, for example, the dependency versions of platforms and frameworks that consist of more than one artifact.
Resource filtering is disabled by default and can be activated in the <resources> child element of the <build> element of our POM, as shown in the following example. We have to set the <filtering> flag of the desired <resource> element to true:
<project>
[...]
<properties>
[...]
</properties>
[...]
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
[...]
</project>This way, all the properties referenced in our resources will be replaced with their real values by the Maven Resource Plugin.
In addition to the Maven properties, resource filtering can also use properties defined in further property files, which are called filters. The properties contained in these files will be used only for resource filtering, and they cannot be referred in our POM. In the next example, we specify an additional property file, app.properties, to be used for resource filtering:
<build>
<filters>
<filter>src/main/filters/app.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>We can specify multiple resource directories with different settings for the <filtering> flag, as follows:
<resources>
<resource>
<directory>src/main/resources-alt</directory>
<filtering>true</filtering>
</resource>
<resource>
<directory>src/main/resources</directory>
</resource>
</resources>In this case, only the resources in the src/main/resources-alt folder will be filtered.