ChatGPT解决这个技术问题 Extra ChatGPT

Updating version numbers of modules in a multi-module Maven project

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>
Your question is misstated and confuses people who have true multi-module ("aggregate") POMs. From your example and from the answers it appears you're really talking about a parent POM, not a multi-module, aggregate POM. See maven.apache.org/pom.html#Aggregation .

S
Sean Patrick Floyd

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.


It would have been great if there was a solution that does not require you to actually change each module. The only alternative I can think of is to always use a snapshot version for the parent-pom.
Additionally to the versions:set one can specify -DgenerateBackupPoms=false, as by default this plugin back ups original pom files.
That's the point of the versions:commit : "Removes the initial backup of the pom, thereby accepting the changes."
A new plugin solves the issue described in this question differently: mojo.codehaus.org/flatten-maven-plugin/examples/…
@MichaelLaffargue mvn versions:commit seems to remove the backup files generated of the previous pom.xml
G
Garret Wilson

The given answer assumes that the project in question use project inheritance in addition to module aggregation. In fact those are distinct concepts:

https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation

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

How do we automate the next version as well just like the build-helper plugin ?
Using Maven 3.5.0 I cannot get this to work. I have project aggregation and only the parent pom got updated. I also tried project inheritance (together with aggregation - "all three rules" from the provided link), and again only the parent pom got updated.
Found the secret make-it-work switch: the starting version of the parent pom and the modules has to be the same! My parent pom was starting with "1-SNAPSHOT" and the modules had "1.0.0-SNAPSHOT". :)
With an aggregator project, the version of the aggregator and versions of the submodules do not have to be the same. (E.g. your aggregator pom may only change rarely and can stay at a particular version, while individual submodules can have their own release cycles). The key property to specify to the versions:set plugin is -DoldVersion='*', on mojohaus.org/versions-maven-plugin/set-mojo.html it explicitly says this property should be specified when processing an aggregator project.
Under what conditions does -DprocessAllModules actually work? It doesn't work for me.
M
Malcolm Crum

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

Thanks, @Crummy, you have saved my day
Or you can use -DoldVersion='*'
Cool, thanks!! Example with SNAPSHOT: mvn build-helper:parse-version versions:set -DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.nextIncrementalVersion}-SNAPSHOT versions:commit
N
Nishant

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

mvn version:set doesn't affect modules.
OK it does when the reactor build is in the same time parent. It's confusing when the structure looks otherwise...
mvn release:update-versions -DautoVersionSubmodules worked fine for me, even if I am not releasing :-)
k
khmarbaise

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.


and look for what specifically?
+1 for bringing up the proper formatting for pom.xml files, but I agree (with @ThorbjørnRavnAndersen) that reading a whole book for this information is overkill. :p
Unfortunately inheriting version information from the parent doesn't remove the burden of having to modify all pom files in the project - because they all reference the parent by version number.
You could use versions-maven-plugin which handles all this stuff or you can use the maven-release-plugin and so you don't need to handle this manually...
It still boggles my mind that people still just drop links here without any regards of the link ever expiring. This renders this answer essentially useless.
Y
Yu Jiaao

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.


I can't find the tag dependencyManagement on pom.xml. Are you thinking on something else?
B
Buhake Sindi

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.


Is having child modules inherit a parent's version a good approach? What if only the child modules change?
This assumes that the root module is the parent, which does not have to be the case.
T
Thomas Mueller

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>
+        

P
Paul Roub

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

M
Mojtaba Mirakbari

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>

This is just too much work
p
parsecer

I was looking for this:

<properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
</properties>

a
ahmednabil88

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 instead of set:

Example:

mvn versions:set-property -Dproperty=revision -DnewVersion="2.0.0"  

mvn versions:commit