3

I have a root pom.xml that acts as a parent for several child pom.xml files, which is great if you have one or two child pom.xml files. I am working on a project that has 50+ child pom.xml files, and several releases going on at once. Everything is great until I need to update the version of the parent pom.xml files, which can be tedious. Is there a way to cascade the version of the parent pom.xml down to all child pom.xml files?

I had the idea to just create a property in the parent pom.xml for the current version, but that's not working.

EDIT

Here is a sample from my child pom.xml files:

<parent>
    <groupId>myGroup</groupId>
    <artifactId>myArtifactId</artifactId>
    <version>1.0</version>  <!-- This is the value that I would like to parameterize in my child pom.xmls -->
    <relativePath>../../pom.xml</relativePath>
</parent>

As an aside, I am using Maven 3.0.3

messivanio
  • 2,263
  • 18
  • 24
bakoyaro
  • 2,550
  • 3
  • 36
  • 63

5 Answers5

2

I assume you having a thing like this:

+--root (pom.xml)
     +--- module1 (pom.xml)
     +---

In the root pom.xml:

<project ..>

  <groupId>the.company.project</groupId>
  <artifactId>the-artifact</artifactId>
  <version>1.0-SNAPSHOT</version>
  ...
</project>

whereas in the childs you should have:

<project ..>

  <parent>         
    <groupId>the.company.project</groupId>
    <artifactId>the-artifact</artifactId>
    <version>1.0-SNAPSHOT</version>
  </parent>

  <artifactId>the-artifact-child</artifactId>

</project>

For such purposes you should use the maven-release-plugin which handles the updating of the version in root as well in childs. If you don't use maven-release-plugin you can use the versions-maven-plugin which can handle the same things.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • I'm trying out the maven-release-plugin, but I'm getting some errors because of a missing scm property. Do you know what the smallest configuration would be? – bakoyaro Apr 22 '13 at 18:07
2

You can do it this way:

Have an aggregator POM project, in which you specify all your child modules and then run this goal on the this aggregator project:

mvn versions:update-parent

This will update all child modules with the new parent version.

Alternatively you can use the same before each release:prepare goal of your child module, thus avoiding creating the aggregator module.

So in case you want to release a child module, you just run this goal:

mvn versions:update-parent release:prepare

This will ensure that the parent gets updated with a new version before it is being prepared for a release.

I read in your comment you are missing an scm tag. Example of usage in case of subversions might be:

<scm>
    <developerConnection>scm:svn:https://your.domain/scm/svn/yourModule/trunk/</developerConnection>
</scm>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <configuration>
                <tagBase>https://your.domain/scm/svn/yourModule/tags</tagBase>
            </configuration>
        </plugin> 
    </plugins>
</build>

Release plugin does not work without a properly configured scm.

You do not need to configure the tagbase tag in release plugin in case you follow "trunk, tags, branches" best practice in your svn repository, see this answer.

Community
  • 1
  • 1
Ev0oD
  • 1,395
  • 16
  • 33
2

I had the same problem and what I did was slightly different than anything suggested so far. Assume that your project has the following folder structure:

parent
+-- child1
     +-- child2_of_parent
     +-- child3_of_parent
+-- child4
     +-- child5_of_child4

Do note that except for child5_of_child4, all the rest of the projects have as parent the top level project parent. This is regardless of the folder structure. Parent pom.xml:

<groupId>...</groupId>
<artifactId>...</artifactId>
<version>1.1-SNAPSHOT</version>

All children pom.xml except for child5_of_child4 that has as parent child4:

 <parent>
  <groupId>...</groupId>
  <artifactId>parent</artifactId>
  <version>1.1-SNAPSHOT</version>
  <relativePath>../parent</relativePath>
 </parent>

You go to the parent directory and change its version from version from 1.1-SNAPSHOT to 1.2-SNAPSHOT. Then you do (more details here):

mvn versions:update-child-modules

As this is not recursive, it only works on the direct children of your parent project. In other words, all sub-modules will be updated to point to parent 1.2-SNAPSHOT except for child5_of_child4.

user1485864
  • 499
  • 6
  • 18
1

In your child pom.xml:

<parent>
    <groupId>groupId</groupId>
    <artifactId>parent.artifactId</artifactId>
    <version>version</version>
    <relativePath>../parent-pom</relativePath>
 </parent>
 <artifactId>child.artifactId</artifactId>
yodamad
  • 1,452
  • 14
  • 24
  • 1
    you don't need to specify a relativePath in such circumstances, cause the parent is the default. – khmarbaise Apr 22 '13 at 14:45
  • It depends on your directories organization. In some cases, you can have children not included in parent directory so you need to specify relativepath ;) – yodamad Apr 22 '13 at 14:54
-1

Just don't put the version in the child poms. It's inherited automatically. It will show up as a warning in Eclipse plugin if you edit there.

djechlin
  • 59,258
  • 35
  • 162
  • 290
  • Sorry, I get this error when I tried your answer: [ERROR] The project myGroup:acceptance-tests:[unknown-version] (C:\git\my_app\1.0\my_app\acceptance-tests\pom.xml) has 1 error [ERROR] 'parent.version' is missing. @ line 8, column 13 – bakoyaro Apr 22 '13 at 15:48
  • 2
    @bakoyaro No. In you need to specify version of parent. You do not specify version of child. – djechlin Apr 22 '13 at 16:15