Reputation: 6420
I have a multi-module maven project. We intend to version all these modules together. But as of now I am ending up hard-coding version in each of the module pom.xml as below
<parent>
<artifactId>xyz-application</artifactId>
<groupId>com.xyz</groupId>
<version>2.50.0.g</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>xyz-Library</artifactId>
<version>2.50.0.g</version>
and the main parent module has the below configuration
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>xyz-application</artifactId>
<version>2.50.0.g</version>
<packaging>pom</packaging>
Upvotes: 439
Views: 480150
Reputation: 18966
Hint:
If your multi-modules maven project uses a project version as a property inside your main POM file for example
<properties>
<revision>1.0.0</revision> <!-- project version/revision -->
...
</properties>
In this case, you can bump your project version by using set-property
:
Example:
mvn versions:set-property -Dproperty=revision -DnewVersion="2.0.0"
mvn versions:commit
And if You need to set-property
without creating the generate Backup Poms:
mvn versions:set-property -Dproperty=revision -DnewVersion="2.0.0" -DgenerateBackupPoms=false
And if You need to automate incrementing the versions and have full control on your version, you can do that by using Build Helper Maven Plugin/ build-helper:parse-version
:
projectVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=project.version -q -DforceStdout)
majorVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=parsedVersion.majorVersion -q -DforceStdout)
minorVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=parsedVersion.minorVersion -q -DforceStdout)
incrementalVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=parsedVersion.incrementalVersion -q -DforceStdout)
nextMajorVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=parsedVersion.nextMajorVersion -q -DforceStdout)
nextMinorVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=parsedVersion.nextMinorVersion -q -DforceStdout)
nextIncrementalVersion=$(mvn build-helper:parse-version help:evaluate -Dexpression=parsedVersion.nextIncrementalVersion -q -DforceStdout)
# given the above variables, you can automate what is the newVersion according to your release management requirements...
# example: the new version [release] > will be same major + increment the minor [ 4.0 > 4.1 ]
mvn versions:set-property -Dproperty=revision -DnewVersion=$majorVersion.$nextMinorVersion -DgenerateBackupPoms=false
# example: the new version [release] > will be increment the major + 0 minor [ 4.0 > 5.0 ]
mvn versions:set-property -Dproperty=revision -DnewVersion=$nextMajorVersion.0 -DgenerateBackupPoms=false
# example: the new version [next development iteration] > will be increment the major + 0 minor + -SNAPSHOT [ 4.0 > 5.0-SNAPSHOT ]
mvn versions:set-property -Dproperty=revision -DnewVersion=$nextMajorVersion.0-SNAPSHOT -DgenerateBackupPoms=false
Upvotes: 7
Reputation: 50087
The solution given above worked for us as well for a long time:
mvn versions:set -DnewVersion=2.50.1-SNAPSHOT
However it stopped working yesterday, and we found it due to a recent bug in a the versions-maven-plugin
Our (temporary) workaround was to change the parent/pom.xml file as follows:
--- jackrabbit/oak/trunk/oak-parent/pom.xml 2020/08/13 13:43:11 1880829
+++ jackrabbit/oak/trunk/oak-parent/pom.xml 2020/08/13 15:17:59 1880830
@@ -329,6 +329,13 @@
<artifactId>spotbugs-maven-plugin</artifactId>
<version>3.1.11</version>
</plugin>
+
+ <plugin>
+ <groupId>org.codehaus.mojo</groupId>
+ <artifactId>versions-maven-plugin</artifactId>
+ <version>2.7</version>
+ </plugin>
+
Upvotes: 8
Reputation: 99
To update main pom.xml and parent version on submodules:
mvn versions:set -DnewVersion=1.3.0-SNAPSHOT -N versions:update-child-modules -DgenerateBackupPoms=false
Upvotes: 5
Reputation: 61
the easiest way is to change version in every pom.xml to arbitrary version. then check that dependency management to use the correct version of the module used in this module! for example, if u want increase versioning for a tow module project u must do like flowing:
in childe module :
<parent>
<artifactId>A-application</artifactId>
<groupId>com.A</groupId>
<version>new-version</version>
</parent>
and in parent module :
<groupId>com.A</groupId>
<artifactId>A-application</artifactId>
<version>new-version</version>
Upvotes: 0
Reputation: 13727
versions:update-child-modules
sounds like what you're looking for. You could do versions:set as mentioned, but this is a light-weight way to update the parent version numbers. For the child modules, it's my opinion that you should remove the <version>
definitions, since they will inherit the parent module's version number.
Upvotes: 4
Reputation: 4869
If you want to fully automate the process (i.e. you want to increment the version number without having to know what the current version number is), you can do this:
mvn build-helper:parse-version versions:set -DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.nextIncrementalVersion} versions:commit
Upvotes: 54
Reputation: 298818
Use versions:set
from the versions-maven plugin:
mvn versions:set -DnewVersion=2.50.1-SNAPSHOT
It will adjust all pom versions, parent versions and dependency versions in a multi-module project.
If you made a mistake, do
mvn versions:revert
afterwards, or
mvn versions:commit
if you're happy with the results.
Note: this solution assumes that all modules use the aggregate pom as parent pom also, a scenario that was considered standard at the time of this answer. If that is not the case, go for Garret Wilson's answer.
Upvotes: 834
Reputation: 21316
The given answer assumes that the project in question use project inheritance in addition to module aggregation. In fact those are distinct concepts:
Some projects may be an aggregation of modules, yet not have a parent-child relationship between aggregator POM and the aggregated modules. (There may be no parent-child relationship at all, or the child modules may use a separate POM altogether as the "parent".) In these situations the given answer will not work.
After much reading and experimentation, it turns out there is a way to use the Versions Maven Plugin to update not only the aggregator POM but also all aggregated modules as well; it is the processAllModules
option. The following command must be done in the directory of the aggregator project:
mvn versions:set -DnewVersion=2.50.1-SNAPSHOT -DprocessAllModules
The Versions Maven Plugin will not only update the versions of all contained modules, it will also update inter-module dependencies!!!! This is a huge win and will save a lot of time and prevent all sorts of problems.
Of course don't forget to commit the changes in all modules, which you can also do with the same switch:
mvn versions:commit -DprocessAllModules
You may decide to dispense with the backup POMS altogether and do everything in one command:
mvn versions:set -DnewVersion=2.50.1-SNAPSHOT -DprocessAllModules -DgenerateBackupPoms=false
Upvotes: 109
Reputation: 51
The best way is, since you intend to bundle your modules together, you can specify <dependencyManagement>
tag in outer most pom.xml
(parent module) direct under <project>
tag. It controls the version and group name. In your individual module, you just need to specify the <artifactId>
tag in your pom.xml
. It will take the version from parent file.
Upvotes: 4
Reputation: 55856
You may want to look into Maven release plugin's release:update-versions goal. It will update the parent's version as well as all the modules under it.
Update: Please note that the above is the release plugin. If you are not releasing, you may want to use versions:set
mvn versions:set -DnewVersion=1.2.3-SNAPSHOT
Upvotes: 33
Reputation: 97348
I encourage you to read the Maven Book about multi-module (reactor) builds.
I meant in particular the following:
<parent>
<artifactId>xyz-application</artifactId>
<groupId>com.xyz</groupId>
<version>2.50.0.g</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>xyz-Library</artifactId>
<version>2.50.0.g</version>
should be changed into. Here take care about the not defined version only in parent part it is defined.
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>xyz-application</artifactId>
<groupId>com.xyz</groupId>
<version>2.50.0.g</version>
</parent>
<groupId>com.xyz</groupId>
<artifactId>xyz-Library</artifactId>
This is a better link.
Upvotes: 12