I am using maven as build tool. I have set an environment variable called env
. How can I get access to this environment variable's value in the pom.xml
file?

- 35,493
- 19
- 190
- 259

- 12,151
- 35
- 108
- 137
-
10you can refer it with ${env.XXXXXXXX} where XXXXXXXX is your variable name. For example ${env.PATH} will give PATH reference. – Seshagiri May 05 '12 at 15:08
-
2But you probably shouldn't. If you make your builds dependent on your environment, they are harder to reproduce. – Stephen C May 05 '12 at 15:11
-
5@StephenC I wouldn't say "shouldn't", but "be very careful." Sometimes a CI environment and a local dev environment look different and environment variables are a way to fill the gaps. – Andrew White May 05 '12 at 15:15
-
i have set environment variable "env". can i use in maven as ${env.env} ? Thanks – user1016403 May 05 '12 at 15:16
-
looks like it works without env, too: ${XXXXXXXX} – weberjn Apr 03 '18 at 09:11
-
1For me, IntelliJ 2019 shows the `${env.XYZ}` reference as red. The variable is correctly expanded at runtime but showing as red at compile time. I therefore have the same question that was originally asked. – djangofan Jul 29 '19 at 22:36
-
@djangofan I am seeing the same thing, but is it working for you even if red? – Mark Han Oct 23 '19 at 18:33
-
1Yep, it does @MarkHan – djangofan Nov 05 '19 at 00:22
6 Answers
Check out the Maven Properties Guide...
As Seshagiri pointed out in the comments, ${env.VARIABLE_NAME}
will do what you want.
I will add a word of warning and say that a pom.xml
should completely describe your project so please use environment variables judiciously. If you make your builds dependent on your environment, they are harder to reproduce

- 62,887
- 36
- 269
- 388

- 52,720
- 19
- 113
- 137
-
3
-
26Be Cautions: all characters of variable_name in your pom must be upper case to be platform independent. Because it's only valid in upper case form running on Windows OS. For example, ${env.M2_HOME} is valid, ${env.m2_home} is invalid, even if you defined a environment variable named m2_home. – Jeff Liu Aug 02 '14 at 10:45
-
I have this in Windows Environment properties (WL_HOME=c:\apps\Weblogic12\wlserver_12.1) but in pom, it return this value c:\apps\Weblogic12\wlserver(without_12.1) any idea where else maven might be picking this up from ? – Anand Rockzz Mar 26 '15 at 23:58
-
Just realized that I was defining a properly called
${WL_HOME} and using that and somehow it referred without the version if I do that. – Anand Rockzz Mar 27 '15 at 00:11 -
It's working fine in **Windows** for IDE & CLI. For **MacOS/Linux/Unix** it's little bit tricky for getting support from IDE where no doubt for **Terminal**, It's working fine. – Śhāhēēd Dec 08 '17 at 16:28
-
4Environment variables can be very useful and they are recommended here e.g. https://12factor.net/. These variables are getting more important because of containers and kubernets: You can simply keep secrets in kubernets and add them to your container environment on start. – Tobske Sep 14 '18 at 07:58
-
i use this only for username/passwords...for example pushing docker builds to hub.docker – Jeryl Cook Mar 08 '19 at 14:02
-
Not: I tried this from the eclipse embedded maven installation doesn't worked for me, But when i try it from the external maven(installed in my PC) it worked like charm. – mallikarjun Apr 27 '19 at 07:12
-
@lhunath has a valid point about use of env variables creating dependencies for your build. Note however, not everything done by Maven is building runnable stuff. For example, putting your SonarQube login in an env variable only changes the code scan and never the code built. – Lee Meador Feb 25 '20 at 20:40
It might be safer to directly pass environment variables to maven system properties. For example, say on Linux you want to access environment variable MY_VARIABLE. You can use a system property in your pom file.
<properties>
...
<!-- Default value for my.variable can be defined here -->
<my.variable>foo</my.variable>
...
</properties>
...
<!-- Use my.variable -->
... ${my.variable} ...
Set the property value on the maven command line:
mvn clean package -Dmy.variable=$MY_VARIABLE

- 1,098
- 1
- 10
- 18
-
7
-
This isn't working for me, the new value of my.variable provided on the command line never overrides the value in the
block. Any ideas? – Daniel Scott Aug 16 '18 at 14:42 -
To me safer, or at least less mysterious, b/c properties can be described in a properties file. However, I realize my solution relies on the Spring framework, which is probably why it doesn't work for Daniel. – EricGreg Aug 17 '18 at 22:42
-
1it's safer because if you fail to change the value via commandline/environment, it still is a valid POM and build, from the value in properties. – foo Apr 07 '20 at 21:42
-
so ${my.variable} in the pom is equivalent to MY_VARIABLE with all caps and underscore in MacOS/Linux when exporting the Variable??? – ennth Feb 16 '21 at 22:36
Also, make sure that your environment variable is composed only by UPPER CASE LETTERS.... I don't know why (the documentation doesn't say nothing explicit about it, at least the link provided by @Andrew White), but if the variable is a lower case word (e.g. env.dummy), the variable always came empty or null...
i was struggling with this like an hour, until I decided to try an UPPER CASE VARIABLE, and problem solved.
OK Variables Examples:
- DUMMY
- DUMMY_ONE
- JBOSS_SERVER_PATH
(NOTE: I was using maven v3.0.5)
I Hope that this can help someone....

- 3,279
- 20
- 30
-
5Environment variables in unix are case sensitive and are traditionally given upper case names so that when you look at the variables set in your shell, you can easily distinguish which are set locally to your shell and which are visible to child processes. Environment variables in Windows do not appear to be case sensitive, but I have not verified that from documentation, only from a small experiment at the command prompt. – legalize Oct 24 '14 at 16:55
-
but in the pom, the variable is all lowercase and separated by a dot (.) but in mac/Linus when exporting its all CAPS with a _ underscore separator correct? – ennth Feb 16 '21 at 22:37
-
If I understand what you're asking .... the answer is no. The name of the environment variable should be exactly the same in the pom as it is declared in the OS. So, transforming underscores for dots is a NO NO. – Carlitos Way Feb 17 '21 at 20:50
Can't we use
<properties>
<my.variable>${env.MY_VARIABLE}</my.variable>
</properties>

- 179
- 1
- 3
-
Its implicit, as opposed to when you pass it with a -D that makes it explicit and overrides the default property value, which might be still useful to setup a zero config environment (e.g. dev) – Technoshaft Apr 03 '18 at 13:30
-
4Does this work? I've tried it and it's not, at least not in my environment – user26270 Dec 23 '19 at 20:04
I was struggling with the same thing, running a shell script that set variables, then wanting to use the variables in the shared-pom. The goal was to have environment variables replace strings in my project files using the com.google.code.maven-replacer-plugin.
Using ${env.foo}
or ${env.FOO}
didn't work for me. Maven just wasn't finding the variable. What worked was passing the variable in as a command-line parameter in Maven. Here's the setup:
Set the variable in the shell script. If you're launching Maven in a sub-script, make sure the variable is getting set, e.g. using
source ./maven_script.sh
to call it from the parent script.In shared-pom, create a command-line param that grabs the environment variable:
<plugin> ... <executions> <executions> ... <execution> ... <configuration> <param>${foo}</param> <!-- Note this is *not* ${env.foo} --> </configuration>
In com.google.code.maven-replacer-plugin, make the replacement value
${foo}
.In my shell script that calls maven, add this to the command:
-Dfoo=$foo

- 104
- 1
- 2
You can use <properties>
tag to define a custom variable and ${variable}
pattern to use it
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<!-- define -->
<properties>
<property.name>1.0</property.name>
</properties>
<!-- using -->
<version>${property.name}</version>
</project>

- 29,217
- 8
- 193
- 205
-
how would you define that variable in macos? i.e. property.name? would it be export PROPERTY_NAME='blah' ? – ennth Feb 18 '21 at 06:50
-
1This does not answer the OP's question of how to access a value from an environment variable, or provide any discussion of why this wold be a better approach than the one's discussed as alternatives to using an environment variable. – J. Gregory Wright Jan 09 '23 at 18:24