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?
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
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
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....
Can't we use
<properties>
<my.variable>${env.MY_VARIABLE}</my.variable>
</properties>
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
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>
Related
The problem: My software uses a library that every developer (and user) has installed in a different location.
The following works in pom.xml:
<project ...>
...
<dependencies>
<dependency>
<groupId>myGroup</groupId>
<artifactId>myName</artifactId>
<version>1.2.3</version>
<scope>system</scope>
<systemPath>C:\...\....jar</systemPath>
</dependency>
</dependencies>
</project>
But when I check this into source control, every developer who needs to change it, has to change the pom.xml, thus having to ignore it at every commit afterwards or to commit partially if he has to change anything else in the pom.xml, such as adding another dependency.
Using a property does not help, it just moves the problem to another location inside the pom.xml.
Using a property and reading it from an external file (properties-maven-plugin) seems not to work since the plugin is called after the dependency checks of e.g. Eclipse: Dynamically adding a Maven dependency from a property
Using environment variables ${env.MY_VARIABLE} seems not to work either: [ERROR] 'dependencies.dependency.systemPath' for myGroup:myName:jar must specify an absolute path but is ${env.MY_VARIABLE} #line 123, column 45
Any ideas on how to solve that?
I would use a repoistory for my jars. Something like nexus or artifactory.
https://www.sonatype.com/nexus-repository-sonatype
https://www.jfrog.com/open-source/
https://binary-repositories-comparison.github.io/
this option works for me:
3. Using environment variables ${env.MY_VARIABLE} seems not to work either: [ERROR] 'dependencies.dependency.systemPath' for myGroup:myName:jar must specify an absolute path but is ${env.MY_VARIABLE} #line 123, column 45
you have to put the jar name included in the path, for example, ${env.MY_VARIABLE/my_jar.jar}.
Also make sure that MY_VARIABLE exists in your environment.
at the end execute the mvn clean and mvn compile commands
I got myself up and running with Spring, maven using Spring Boot. You may check the below link for details -
https://ashikuzzaman.wordpress.com/2015/06/04/spring-with-maven-using-spring-boot/
In my pom.xml I have the following properties defined.
<properties>
<java.version>1.7</java.version>
<!-- The main class to start by executing java -jar -->
<start-class>com.github.ashikuzzaman.javaapichecks.spring.RawLinkedListTypes</start-class>
</properties>
I wanted to pass one or more runtime arguements to get into the arguement list that main() accepts. Can I do this via a parameter passing in start-class or main-class?
Suppose you are trying to give some value for java.version while you are using mvn package command from terminal. Then you can use it -
mvn package "-Djava.version=1.7"
Using java and Maven, what is the convention for maven properties?
I am posting 2 examples here, both of which are in widespread usage. Which one is correct, according to convention?
Example A
<properties>
<hibernate.version>4.3.8.Final</hibernate.version>
<hsqldb.version>2.3.2</hsqldb.version>
<log4j2.version>2.0.2</log4j2.version>
</properties>
Example B
<properties>
<hibernateVersion>4.3.8.Final</hibernateVersion>
<hsqldbVersion>2.3.2</hsqldbVersion>
<log4j2Version>2.0.2</log4j2Version>
</properties>
Edit:
Here is a link to a Maven Properties Guide. Some examples of maven properties include ${project.build.directory} (dot case) and ${project.build.outputDirectory} (both dot case and camel case).
And the official documentation Maven POM Reference suggests an example property named <someVar> (camel case).
After reading the relevant documentation, the answer to this was clear all along.
The apparent conflict between dot.case and camelCase is that one is used to reference the hierarchical structure within the POM whilst the other is used for variable naming.
For example, let us look at ${project.build.outputDirectory}. The dot notation here, as far as I can understand, refers to the pom structure where the variable is located, whereas the variable name itself is indeed in camel case.
<project>
<build>
<outputDirectory>/opt/foo</outputDirectory>
</build>
</project>
In other words, the convention is as follows:
To refer to variables located elsewhere in the POM, combine path segments such as project or build with the . separator, i.e. use dot.case. Examples:
project.build.<variable>
maven.compiler.<variable>
To name the actual path segments, including the variable name itself (last segment), use lowerCamelCase. Examples:
outputDirectory (as in project.build.outputDirectory)
target (as in maven.compiler.target)
It is worth noting that most open source projects (including e.g. Spring Boot, pre-Gradle-migration - see here) use .version as a path segment and not as an addition to the variable name.
Consistency is the most important consideration. If your codebase is using someDependencyVersion, stick to that - else prefer someDependency.version.
I may be late to the party, but here's my 2 cents.
Consider you may want to check if there's a newer versions available. You have to find each dependency reference within the pom to know the library's groupId and artifactId.
On the other hand, if you use a naming convention shown below, you immediately know whether the version is a reference to a groupId or an artifactId and you can just copy-paste it and search for latest version.
<properties>
<ch.qos.logback.version>1.2.5</ch.qos.logback.version>
<logstash-logback-encoder.version>6.6</logstash-logback-encoder.version>
</properties>
Is it possible to do this?
For example could one do something like:
System.getEnv("$(env.BUILD_URL)");
I do not have access to Jenkins, so can't try it out myself :(
Any help would be greatly appreciated.
Assuming you're using Maven (you've tagged this question as such), I simply add the following to my pom.xml file:
...
<properties>
<!-- Hudson properties: see http://wiki.hudson-ci.org/display/HUDSON/Building+a+software+project#Buildingasoftwareproject-HudsonSetEnvironmentVariables -->
<jenkins.buildId>${env.BUILD_ID}</jenkins.buildId>
<jenkins.buildNumber>${env.BUILD_NUMBER}</jenkins.buildNumber>
<jenkins.buildTag>${env.BUILD_TAG}</jenkins.buildTag>
<jenkins.cvsBranch>${env.CVS_BRANCH}</jenkins.cvsBranch>
<jenkins.executorNumber>${env.EXECUTOR_NUMBER}</jenkins.executorNumber>
<jenkins.hudsonUrl>${env.HUDSON_URL}</jenkins.hudsonUrl>
<jenkins.javaHome>${env.JAVA_HOME}</jenkins.javaHome>
<jenkins.jobName>${env.JOB_NAME}</jenkins.jobName>
<jenkins.svnRevision>${env.SVN_REVISION}</jenkins.svnRevision>
<jenkins.workspace>${env.WORKSPACE}</jenkins.workspace>
</properties>
...
...and then from your code you can simply do a:
String url = System.getProperty("jenkins.hudsonUrl"); // could be null
Putting these into properties makes life more simple for my purposes, especially when using Maven profiles to control my builds. For example, I make sure to create a "jenkins" profile that is activated when I build on a Jenkins build server. When this is done, all the aforementioned jenkins properties are set. When not run as a jenkins profile, those properties are set to some other default value. Anyway, that's another topic, but food for thought. Hopefully it make sense.
I am new to maven. i have a project and it has a pom. inside the pom there is a dependency as below:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>some-project</artifactId>
<version>${originalVersion}</version>
<scope>compile</scope>
</dependency>
My question is where is ${originalVersion} value coming from?
Thanks!
It is either defined somewhere else in the pom, in a parent-pom (there can be several of those, because parents can have parents too), or via a profile (that might be defined somewhere else, like your settings.xml). It could also have been passed as a command-line parameter to maven, but you'd probably have noticed that.
originalVersion is not a standard Maven property so it must appear elsewhere such as in a parent pom, like this:
<properties>
<originalVersion>1.2</originalVersion>
</properties>
See Maven Properties Guide
It comes from a property in your pom.xml.
Something like that:
<properties>
<originalVersion>1.0</originalVersion>
</properties>
Look for a <properties> section in the pom.xml file, there must be a entry like <originalVersion>...</originalVersion>.
Check the properties sub section on the maven tutorial page. It says, following are the possible ways to reference a vairable
env.X: Prefixing a variable with "env." will return the shell's environment variable. For example, ${env.PATH} contains the $path
environment variable (%PATH% in Windows).
project.x: A dot (.) notated path in the POM will contain the corresponding element's value. For example:
1.0 is accessible via
${project.version}.
settings.x: A dot (.) notated path in the settings.xml will contain the corresponding element's value. For example:
false is accessible via
${settings.offline}.
Java System Properties: All properties accessible via java.lang.System.getProperties() are available as POM properties, such
as ${java.home}.
x: Set within a element or an external files, the value may be used as ${someVar}.