I am trying to dynamically pass the parent pom version in my pom as shown below.
<parent>
<groupId>com.maventest</groupId>
<artifactId>myproject</artifactId>
<version>${env.myversion}</version>
</parent>
I have tried with both environment variable as shown above and also tried with passing variable with -D and then access as ${myversion}. None is working for me.
Can someone kindly help.
This does not work because maven resolves the dependencies in the first step before resolving the variables.
Starting with Maven 3.5.0-beta-1 you can use the ${revision}, ${sha1} and/or ${changelist} as placeholders for the version in your pom file. These are three special properties that will be resolved earlier.
You can look for "Maven CI Friendly Versions" for further information: https://maven.apache.org/maven-ci-friendly.html
Related
Given a property defined inside the pom, can I refer to that property from the command line?
This is what I would like to achieve:
# instead of:
mvn versions:set -DnewVersion=x.y.z
# something like this:
mvn versions:set -DnewVersion=properties:library.version
This way I can manage my multi-modular project version in one place and update all modules at the same time.
Is something like this possible? Perhaps by preconfiguring the version plugin inside the pom itself and completely omit the newVersion property from the command line?
You actually have a better way to reach you goal:
https://maven.apache.org/maven-ci-friendly.html
Idea is to use property ${revision} instead of version value.
So in all you POMs you do something like that:
Parent POM:
<groupId>my.group</groupId>
<artifactId>my.artifact</artifactId>
<version>${revision}</version>
Sub-modules:
<parent>
<groupId>my.group</groupId>
<artifactId>my.artifact</artifactId>
<version>${revision}</version>
</parent>
Now at the root of the project (where you project parent POM) you provide /.mvn/maven.config file (FYI: https://maven.apache.org/docs/3.3.1/release-notes.html (JVM and Command Line Options)):
/.mvn
maven.config
/submodule-one
/submodule-two
pom.xml
maven.config contains setting of the version to the property:
-Drevision=1.1.10-SNAPSHOT
And do not forget to provide in the parent POM flatten-maven-plugin configuration with flattenMode=resolveCiFriendliesOnly, exactly like described in the documentation by link above.
As result, maven.config is the only place where you need set version for all you modules.
And you not need to change anything in POMs when you want to change version.
But to make it works you need at least maven 3.5.0-beta-1.
P.S. you can see all of that in my maven testing project:
https://github.com/Gmugra/net.cactusthorn.maven
It's actually very easy, just provide the newVersion property in the pom:
<properties>
<library.version>1.0.0</library.version>
<newVersion>${library.version}</newVersion>
</properties>
Then simply execute versions:set without providing the property and it will pick up on the property from the POM instead:
mvn versions:set
Alternative solution:
You can also skip the property and have maven dynamically update the current version:
The following increases patch version:
mvn build-helper:parse-version versions:set -DnewVersion=${parsedVersion.nextMajorVersion}.${parsedVersion.minorVersion}.${parsedVersion.IncrementalVersion} versions:commit
This is built into Maven and works out-of-the-box.
What's the best structure for a (multi-module) Maven project which should build "in the wild" without any Maven repository manager and can easily build within my organization where deployments should happen to my Maven repository manager?
Ideally, I would have two different paren POMs for each situation.
But unfortunately, I can't use a Maven property to pass the correct value for each situation, because the property expression in the parent POM reference doesn't get interpolated, if I try something like
<parent>
<groupId>org.example</groupId>
<artifactId>${root.pom}</artifactId>
<version>1.0-SNAPSHOT</version>
<relativePath/>
</parent>
...
<properties>
<root.pom>wild-parent</root.pom>
</properties>
Added a minimalistic project which shows a crude approach to solve this by patching the parent POM via sed.
This response on the maven-users mailing list pointed me in the direction to use Maven properties to pass in the in-house specifics.
I updated the example project.
I have the following POM structures:
/home/projects/parent/pom.xml
<project>
<groupId>com.my.group</groupId>
<artifactId>project-super-parent</artifactId>
<version>${major.version}.${minor.version}</version>
<packaging>pom</packaging>
<properties>
<major.version>7</major.version>
<minor.version>5</minor.version>
<current.release.version>${major.version}.${minor.version}-SNAPSHOT</current.release.version>
...
</properties>
....
</project>
/home/projects/module1/pom.xml
<project>
<groupId>com.my.group</groupId>
<artifactId>module1</artifactId>
<version>${current.release.version}</version>
<packaging>jar</packaging>
<parent>
<groupId>com.my.group</groupId>
<artifactId>project-super-parent</artifactId>
<version>${major.version}.${minor.version}</version>
<relativePath>../parent</relativePath>
</parent>
...
</project>
Notice that the module does not know the version of it's parent - it uses a property defined in the parent, so this is a kind of a chicken & an egg problem.
The weird thing is - that this works - so when I want to change the major version of the product - I only change a single pom file (the parent).
The limitations to this solution is that I have to have all POM files on the file system.
My questions are: should this even work? How exactly does it work? Is it likely to stop working when I upgrade to maven 3? Is this a commonly used solution or an abuse of the system?
Currently using Maven 2.2.1 and Java 7.
Is this a commonly used solution or an abuse of the system?
That is not common, at least I have never seen it before. The versioning you have in parent/pom.xml and module1/pom.xml will cause a confusion. The parent has a RELEASED version of 7.5, while module1 has a SNAPSHOT version of 7.5. You should not be developing 7.5-SNAPSHOT if 7.5 is already released.
The simplest way to avoid duplication is to maintain the version only in the parent. You can just omit the version declaration in module1. Take a look another project, e.g. maven-3 source code for example. You will be able to see the the version is only declared in the parent pom, and not in any of its child poms.
maven-release-plugin will help you handle the version upgrade and release them for you.
Omitting the version element from the child pom gives error.
Property can be used in Main pom and the same can be inherited by child pom's. When you run the Main pom, build will result in success. Problems are
That you can not build the child pom independently
This does not work in case of transitive dependencies
if you upgrade to Maven 3 in future than it will give error "Non-resolvable parent pom
These problems can be resolved if we are able to update the project pom file as part of the build process before it gets installed in local repository
Per Maven documentation Maven will only look in local and remote repos for a parent pom after it fails to find it locally. The best solution I've found to dummy this out is by adding
<relativePath>.</relativePath>
which is obviously a kludge and produces warnings (as it well should). Maven seems to be like file-system coupling when dealing with parent modules and multi-module projects so this is the only way I see to have both of those co-exist without something that feels obviously wrong (e.g. inheriting from a filesystem child).
You reference the parent pom using the tag:
<parent>
<groupId>com.mycompany</groupId>
<artifactId>my-parentpom</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
You must install the parent pom into your local repo using the mvn install -N command from the directory that contains the parent POM.
I have a maven project - it is a plugin for jenkins. It's parent should be a:
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.414</version>
</parent>
But at the same time this plugin can be also used for hudson, without changing any line of code. But the parent project for it should be:
<parent>
<groupId>org.jvnet.hudson.plugins</groupId>
<artifactId>hudson-plugin-parent</artifactId>
<version>2.0.1</version>
</parent>
Can I specify 2 different profiles for that and use them to build plugin for jenkins or hudson accordingly? So that I call something like that:
mvn package -P jenkins
or
mvn package -P hudson
I have tried to specify properties in profiles, but those are not replaced by their values inside the <parent> tag. So is there any other possibility to build plugin for both, but with as much as possible common code and files?
Added: So, if I cannot do that, what should I do then? How to refactor? What the new structure should be?
As already mentioned, this is not possible.
Also, it is not possible to set a property for the parent's version as the interpolation for that happens a lot earlier than the handling of the profiles.
I would suggest that you create a masterbuild project as follows:
master
|-plugin-jenkins
|-plugin-hudson
|-plugin-assembly
The master should build all three as usual. However, in the assembly, you could add each of the two plugins as dependencies in separate profiles. And... each of these plugins can have the parent you like.
This is obviously somewhat a deviation from the Maven convention, but I believe it is a solution to your problem.
It's not possible because the tag "parent" is not available in the profiles section of the pom.
Currently we decided to stick with 1 repository and 2 separate pom.xml files, giving maven key which pom.xml use to build the project.
mvn package -f pom-jenkins.xml
mvn package -f pom-hudson.xml
No you cannot do that. you will have to refactor somehow to avoid the necessity.
As mentioned already not possible. I would suggest to make separate projects for jenkins plugin and hudson plugin. I assume that in not that far future that will not work anymore cause Hudons and Jenkins will diverge.
In general, you should be able to set the {group,artifact}Id and version of the parent POM via Java System Properties or Environment Variables, but it seems there is a Bug in Maven which will only be fixed in 4.x:
https://issues.apache.org/jira/browse/MNG-624
Another solution is to delegate the inclusion of the parent POM to your own parent POMs which you reference in the relativePath element, and change the content of the target e.g. via a symlink or cp command.
So in the main POM you would write:
<parent>
<groupId>org.mycompany.project</groupId>
<artifactId>foo-artifact</artifactId>
<version>1.0.0</version>
<relativePath>./my-parent.pom</relativePath>
</parent>
And in my-parent-jenkins you would just put:
<groupId>org.mycompany.project</groupId>
<artifactId>foo-artifact</artifactId>
<version>1.0.0</version>
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.414</version>
</parent>
The same project information with the block for hudson you put in my-parent-hudson.pom.
No you can either use
ln -s my-parent-jenkins.pom my-parent.pom
or
ln -s my-parent-hudson.pom my-parent.pom
to include the respective parent POM without the need to maintain two different main POM files for your project.
In case POM does not exist at the place referenced in relativePath, Maven will look up the POM in the remote repository[1], which is also an easy way to overwrite a parent POM locally.
[1] http://maven.apache.org/components/ref/3.3.9/maven-model/maven.html#class_parent