How to refer environment variable in POM.xml?

Environment variables and build reproducibility

Build reproducibility is a primary aspect of any CI/CD process. It's important to remember, though, that environment variables, despite their versatility, can introduce unpredictability. Always document necessary environment variables, and it's a good practice to set default values:

<properties>
    <!-- When JAVA_HOME isn't set, we'll play with a safe default -->
    <javaHome>${env.JAVA_HOME:-/default/path/to/jdk}</javaHome>
</properties>


Here, /default/path/to/jdk acts as the fallback if JAVA_HOME isn't set.

Profiles: managing project configurations like a Pro

In a heterogeneous environment, Maven profiles can serve as a useful tool to manage different configurations. Check the following code snippet in your pom.xml file:

<profiles>
    <profile>
        <id>production</id>
        <properties>
            <!-- We'll replace this later -->
            <envConfig>${env.PROD_DB}</envConfig>
        </properties>
    </profile>
</profiles>


Invoking Maven with this profile is carried out from the command-line:

mvn clean install -Pproduction


Trouble in paradise? Error-proofing your setup

Errors can pop up when you least expect them. Before your code goes into production, confirm the existence of environment variables required for your build process:

#!/bin/bash
# Let's make sure JAVA_HOME is set
: ${JAVA_HOME:? "ERROR: JAVA_HOME is not set in your environment."}
# Time to invoke Maven now!
mvn clean install


The build will be interrupted if JAVA_HOME isn't set, safeguarding against surprises.

Plugin configurations and environment variables: A dynamic duo

Plugins can also be configured using environment variables. Take the maven-replacer-plugin for instance:

<plugin>
    <groupId>com.google.code.maven-replacer-plugin</groupId>
    <artifactId>maven-replacer-plugin</artifactId>
    <version>1.5.3</version>
    <executions>
        <execution>
            <phase>prepare-package</phase>
            <goals>
                <goal>replace</goal>
            </goals>
            <configuration>
                <!-- Before result is served, we replace tokens -->
                <file>${project.build.directory}/config/app.properties</file>
                <token>@envVar@</token>
                <value>${env.ENV_VARIABLE}</value>
            </configuration>
        </execution>
    </executions>
</plugin>


Here, @envVar@ in the app.properties file would be replaced with the value set in ENV_VARIABLE. Clever, right?

Case sensitivity and compatibility checks: Cross your T's and dot your i's

Traditionally, environment variables are upper-case. Ensure you're using the same naming conventions:

<buildNumber>${env.BUILD_NUMBER}</buildNumber>


Also verify your Maven version supports environment variable expansion to avoid unexpected outcomes.

Advanced substitution techniques

At times, you need more than simple substitution, you need creative alternatives. Consider scripting or use plugins for more complex substitutions:

source ./maven_script.sh
mvn -Dproperty.file=env.properties clean install


The above does two things—maven_script.sh sets up your environment variables, before seamlessly importing them into your Maven build without hardcoding them directly into pom.xml.