39

I have a multi-module project. 

parent POM (1.0-SNAPSHOT)
|-- module1 (1.0-SNAPSHOT)
|-- module2 (1.0-SNAPSHOT)
`-- module3 (1.0-SNAPSHOT)

When I execute mvn release:prepare it verify that parent POM has a SNAPSHOT version and all dependent modules don't have a SNAPSHOT version. How automatically update all child modules from SNAPSHOT to the next release version?

I would like automatically increment version for all modules.

Peter Mularien
  • 2,578
  • 1
  • 25
  • 34
eugenn
  • 1,638
  • 6
  • 23
  • 38
  • Using a "fixed" parent version as [defined here](http://jira.codehaus.org/browse/MNG-624?focusedCommentId=242865&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_242865) might also help you. – James Selvakumar Nov 12 '10 at 10:15
  • here is the link to the relevant comment in the linked discussion : http://jira.codehaus.org/browse/MNG-624?focusedCommentId=242865&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-242865 – barjak Dec 05 '11 at 15:31

4 Answers4

36

A flexible way to set poms versions, multi-modules projects included, is Versions Maven Plugin.

mvn versions:set -DnewVersion=your_new_version

It will adjust all pom versions, parent versions and children versions in a multi-module project.

then

mvn versions:commit

or

mvn versions:revert
charego
  • 137
  • 9
aymens
  • 714
  • 9
  • 7
  • 9
    `commit` and `revert` act on the back-up pom files created during `set`, which is IMO unnecessary since I'm using version control and could simply revert to what's in git. By adding `-DgenerateBackupPoms=false` to the `set` command, there is no need for either `commit` or `set` afterwards. My 2 cents. – Adam Feb 13 '17 at 10:25
  • 2
    It's a kind of a dry run that lets user check the results before doing it effectively. But yeah, you can go straight forward also. But in case of a mistake, it might be less funny to revert a git commit than that set-commit IMHO. – aymens Feb 13 '17 at 10:37
  • oh it's definitely handy in some situations, but the naming misled me for a while and I had to look up in the docs exactly what it did, just to be sure. I think I would have called the command `versions:deleteBackupPoms` and `versions:revertToBackupPoms`. – Adam Feb 13 '17 at 11:05
31

The release plugin can handle that. Did you check Updating POM Versions? But... I don't get something. Changing the version in the POMs from x-SNAPSHOT to a new version and bumping the version in the POMs to a new value y-SNAPSHOT should be done by release:prepare as explained in Prepare a Release. What is going wrong when using this goal?

Update: The autoVersionSubmodules parameter might be what you're looking for. From the Prepare a Release example:

Multi-module projects

You will be prompted for the version number for each module of the project. If you prefer that every module gets the same version as the parent POM, you can set the option autoVersionSubmodules to true. Now you will be asked only once for the release version and the next development version.

Snippet of parent pom.xml

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>x.y.z</version>
            <configuration>
                <goals>deploy</goals>
                <autoversionsubmodules>true</autoversionsubmodules>
            </configuration>
        </plugin>
    </plugins>
</build>
anotherdave
  • 6,656
  • 4
  • 34
  • 65
Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • For example command mvn versions:set -DnewVersion=1.0 update the parent POM and modules versions. But I don't want to update the parent version... What is the best practices for releasing the multi-module projects? – eugenn Feb 26 '10 at 14:40
  • release:prepare require that all modules have a non-SNAPSHOT version Therefore I should manually change versions for all modules. For instance the project consist of 15th modules. Therefore I finding a way how to update automatically all modules. – eugenn Feb 26 '10 at 14:47
  • 1
    @eugenn No, you don't have to change that manually, the `release:prepare` goal does it for you (check the link again). – Pascal Thivent Feb 26 '10 at 15:12
  • Thank you Pascal, you are right! release:prepare works well. Possible I have some configurations issues with my parent POM. – eugenn Feb 26 '10 at 18:39
  • A new maven plugin comes to adress this problem: http://mojo.codehaus.org/flatten-maven-plugin/examples/example-multiple-versions.html – Stephan Jun 12 '14 at 14:49
  • @eugenn But if you l leave the version of parent unchanged this will cause problems. I did myself. When you release a new version you will want to update dependencies that are on parent and you will screw up all projects but last version. Be careful! – Gonzalo Aguilar Delgado Feb 19 '15 at 12:42
7
  1. Make the version of all sub-project be defined in its parent pom.xml.

  2. Make sure all sub-projects versions are the same to their parent's version.

    <groupId>com.xyz</groupId>
<artifactId>module-1</artifactId>
<packaging>jar</packaging>

<parent>
  <groupId>com.xyz</groupId>
  <artifactId>xyz-parent</artifactId>
  <version>1.0.123-SNAPSHOT</version>
</parent>

     

    <?xml version="1.0" encoding="UTF-8"?>
<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">

  <modelVersion>4.0.0</modelVersion>
  <artifactId>xyz-parent</artifactId>
  <groupId>com.xyz</groupId>
  <version>1.0.123-SNAPSHOT</version>
  <packaging>pom</packaging>
  <name>xyz-parent</name>

  <dependencyManagement>
    <dependencies>

    <!-- Message -->
    <dependency>
      <groupId>com.xyz</groupId>
      <artifactId>module-1</artifactId>
      <version>${project.version}</version>
    </dependency>

    <dependency>
      <groupId>com.xyz</groupId>
      <artifactId>module-2</artifactId>
      <version>${project.version}</version>
    </dependency>

  </dependencyManagement>
</project>

  3. Create another pom.xml to group those project together.

    <modules>   
  <module>../xyz-parent</module>
  <module>../module-1</module>
  <module>../module-2</module>      
</modules>

  4. Then update the parent project's version and then build it by below command.

    mvn versions:set -DnewVersion=1.0.1004-SNAPSHOT
mvn clean install

  5. Then update the parent's version which is defined in those sub-project to the latset one

    mvn -N versions:update-child-modules

  6. Then build them together.

    @echo on
cd   .\xyz-parent
call mvn versions:set -DnewVersion=1.0.1004-SNAPSHOT -o
call mvn versions:commit -o
call mvn clean install -o
:::http://www.mojohaus.org/versions-maven-plugin/examples/update-child-modules.html
cd ..\xyz-buildaggregate-ide
call mvn -N versions:update-child-modules -o
call mvn clean install -o
user3571276
  • 101
  • 1
  • 3
  • @DoctorWho Yes, I've tested it on 3.6.0 and it works. It's still versions-maven-plugin and more information including versions info may be found here http://www.mojohaus.org/versions-maven-plugin/usage.html – mpoznyak Nov 05 '19 at 09:13
3

There is a potentially better option over at https://issues.apache.org/jira/browse/MNG-624?focusedCommentId=14415968&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14415968

That is a workaround for the fact that you can't refer to the top level pom in the sub-module poms without having an explicit version listed. (which is what bug MNG-624 is about) It explains how you can have a single location for the version (in a top-level profiles.xml file), and simply have a property references in all the pom.xml files (i.e. ${currentVersion})

However, in this scheme release:prepare probably won't update profiles.xml for you.

vadipp
  • 877
  • 1
  • 12
  • 22
Eric
  • 5,137
  • 4
  • 34
  • 31