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}.
Related
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>
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
My maven distributionManagement section in my base pom.xml for the site looks like this:
<distributionManagement>
<site>
<id>main-site</id>
<name>Main Artifact Site</name>
<url>scp:/somurl/site/${project.groupId}/${project.artifactId}/${project.version}</url>
</site>
</distributionManagement>
We have a base pom.xml, which several projects inherit from. These projects, in turn, have several modules (each with their own poms).
As you can see, the url we pass takes care of uniquely identifying each project/model. Maven appends an extra artifactId after the version for each inherited pom. I would like to stop that behavior. It leaves us with url's like
http://someurl/site/com.whatever.something/some-project-parent/1.14/some-project-parent
http://someurl/site/com.whatever.something/some-project-module/1.14/some-project-parent/some-project-module
I would like for these urls to look like
http://someurl/site/com.whatever.something/some-project-parent/1.14/
http://someurl/site/com.whatever.something/some-project-module/1.14/
The solution I have found is not DRY. It involves copy/pasting this distributionManagement section into every pom.xml.
Any ideas on how to stop this behavior? Thanks in advance!
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>
I have a Maven projects A and B where B depends on A. A defines a class Foo, to which I added a field x, increased the version number, and did mvn install, then matched the version number in B/pom.xml, and did mvn compile, to see an error that there was no field x.
I deleted A/target, B/target and ~/.m2/repository/A, and repeated the procedure, to see the same error message.
Now I am baffled. The error itself might just be a mistake on my part, but I would first like to rule out the possibility that an "old" class file is being cached somewhere. To do this I need a thorough way to delete all class files and jars.
Is there a comprehensive list of all the places that class files can be cached?
I know, I have missed the bus here, but adding this info, in case someone else needs this.
By default, Maven local repository is default to .m2 folder :
Unix/Mac OS X – ~/.m2
Windows – C:\Documents and Settings\{user-name}\.m2 or C:\Users\{user-name}\.m2
But this is very much configurable, via a settings.xml
Location of settings.xml is usually :
{M2_HOME}\conf\setting.xml or {M2_HOME}\setting.xml
In the settings.xml, look for the entry:
<!-- The default local repository or 'cache' is set to %HOME%\.m2\repository.
You can override the default by using the <localRepository> tag below. -->
<!-- <localRepository>C:\path\to\repository</localRepository> -->
<!-- Mirrors are defined here. "<mirrorOf>*</mirrorOf>" is set to catch any
additional repositories that appear, and instead use the AEDC Build
Repository. -->