Igor's Blog

Back in 2015 I wrote about getting around Maven's parent-child project version dependency issue, that was with Maven 3.2.2. Now that Maven 3.5 has been released the same approach doesn't work so I had to rethink how to handle my submodule builds going forward.

Update (19-Jun-2017) - After looking at this more and reading through Maven CI Friendly Versions I've updated this post to reflect how this should be done with Maven 3.5.

My new approach is to set up the parent POM as follows (this actually stays the same as in my previous post):
 Parent POM
<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<groupId>maven.test1</groupId>
<artifactId>maven-test1-parent</artifactId>
<version>${revision}</version> <!-- update 19-Jun-2017 - this is not changed -->
<properties>
<revision>42.0</revision>
</properties>
<name>${project.artifactId}</name>
<description>Main POM file for ${project.artifactId}</description>
<packaging>pom</packaging>
<modules>
<module>Child1</module>
</modules>
</project>


The difference to the previous approach being that the project.version is set to a constant "1.0", but I am still keeping the "revision" property set to "42.0" as before (however this is more or less just a default value now if no revision is specified on the command line, see below).

Update (19-Jun-2017) - the parent POM doesn't change.

The child/sub-module POM now changes to this:
 Child POM
<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>maven.test1</groupId>
<artifactId>maven-test1-parent</artifactId>
<version>${revision}</version> <!-- this is changed from [1.0,99.0) to ${revision} -->
</parent>
<artifactId>maven-test1-child1</artifactId>
<name>${project.artifactId}</name>
</project>




The parent reference now gets a constant version string, but the version of the module itself is still variable and easy to set via the parent POM file. The only down side of this is that if the parent POM changes, you would have to update all of the modules to reference the new parent version, this should be manageable though since parent POM changes should be rare.

Update (19-Jun-2017) - the parent reference is now ${revision} and since the parent POM sets its version to ${revision} as well, the child POM will inherit that.

So this approach still lets you version your modules from one place and removes the need to use the hack-ey parent version range string. This also works in Maven 3.3.3.

Also since the ${revision} property can be set via the command line, there is no need to update the parent POM whenever the revision for the build changes, you can just do this:
 Command
mvn clean install -Drevision=42.1


-i

comments powered by Disqus
Other posts you may like...
Programming, DIY, Games, Hacks, and Tech

Recent Blog Posts

A guide for plotting your hard drive for Burstcoin mining on a Mac using mjminer

Replacing a broken hard drive in a Samsung Story Station

Fix Java applications slow start and net connection times on macOS sierra

Pierre Cardin Leather Computer Bag (PC2278)

How to stop SSH remote host disconnecting your session

Using PayPal PHP SDK on Google App Engine

Use the Touch Bar to lock your Mac with a single button press

Multi module builds with Maven 3.5 and the parent-child pom version management

Google App Engine local dev server DataStore becoming corrupted after a bad GQL statement is run

Unboxing my new 2017 2.9Ghz 15" MacBook Pro

Recent Galleries

Monument Valley 2 is released and does not disappoint

Space Food - Chocolate Ice Cream with Chocolate Chips

Legeod Star Wars AT-DP kit

DIY spare parts computer build with a RAIDMAX Anura case

Fake 'Lepin' brand Lego packaging

Hardwood garden bench with clear resin void filler

Fixing a 3D printer extruder that stopped heating up

Easily increase disk space in a Lenovo Ideapad 100S 14" laptop with an M.2 SSD

Making a multi-piece 3D printed solder spool holder stand

DIY indoor apartment grow light wiring

My Other Web Sites

Igor and Elise's Travels
Riverside Expressway Cam
300 George St Blogumentary

My Online Tools

UUID to OID Converter
Guru JSON-RPC Tester
Extrudifier Object Designer
Travel ┬ÁBlog

Blogs and Friends

Matt Moores Blog
Georgi's FlatPress Guide
Perplexing Permutations
The Security Sleuth
Ilia Rogatchevski
Travelling Fairy

Blog Activity

Blog Activity
You decide - follow me or not, more great content awaits if you do!
     
Don't show this again