How to force an arbitrary parent version when using mvn versions:update-parent?

Question

(Rephrasing the question to give a better understanding) To elaborate on my issue which wasn't detailed enough, these are the following cases I encountered: projects: A and B. The root pom of A is the parent of project B.

Because of some constraints to our release process (this is to give some current context, but this should not be taken as the main drive to circumvent the issue at hand) , I need to change the version of both projects.

If I change the version of A, then change the version of B, I get the following error message:

mvn versions:update-parent -DallowSnapshots -DgenerateBackupPoms=false -DparentVersion="6.4.1-SNAPSHOT" 
[WARNING] Not updating version: could not resolve any versions

If I change the version of A, call mvn clean install on A (which I could live with, although I would prefer to be able to change the version and parent of all my projects at once, in scripts, without intermediate, possibly-failing, builds), then the above command on B works but only if the specified parent version is the latest available. Otherwise I get:

[INFO] Current version of parentGroup:parentArtifact:pom:7.0.12 is the latest.

Which means I cannot use the mvn versions:update-parent command to change the parent version on maintenance branch.

Is there a way to make mvn versions:update-parent respect the required parent version? (regardless of whether it can be found locally, on the nexus repository or not yet at all)

---

edit: additional info with -X (removed irrelevant parts, emphasis mine)

[DEBUG] Configuring mojo 'org.codehaus.mojo:versions-maven-plugin:2.5:update-parent' with basic configurator -->
[DEBUG]   (f) allowSnapshots = true
[DEBUG]   (f) generateBackupPoms = false
(...)
[DEBUG]   (f) parentVersion = 7.0.11
[DEBUG] Determining update check for artifact groupId:artifactIdProjectA (C:\Users\donckels\.m2\repository\.......\artifactIdProjectA\maven-metadata-....-repository.xml) from ....-repository (http://..../nexus/content/groups/public)
(....)
[DEBUG] Searching for ....-repository.maven-metadata-....-repository.xml.lastUpdated in resolution tracking file.
[DEBUG] Reading resolution-state from: C:\Users\donckels\.m2\repository\.....\artifactIdProjectA\resolver-status.properties
(....)
[DEBUG] Proposal is to update from 7.0.12 to 7.0.12
[INFO] Current version of groupId:artifactIdProjectA:pom:7.0.12 is the latest.

Even though I specified 7.0.11, it ends up with:

[DEBUG] Proposal is to update from 7.0.12 to 7.0.12

Fulmar

"or not yet at all"; well... no. Did you try mvn update-versions or mvn versions:set directly on the parent project first? Then mvn versions:update-parent on the main project. – Pontiac

Yes, I did exactly this (mvn versions:set) on the parent project A first. Then I tried updating the separate child project B. As explained, while I'd rather have my scripts do all the updates at once, then run the builds, I can live with a "update, build, update next, build next" process. What I still need, though, is to be able to choose the parent version, regardless of it being the latest available or not. – Ionic

You mention an [info] (not blocking) message in your question. What error message do you get when updating the parent version in B? – Pontiac

There is no error message. Maven just leaves the pom as it is. – Ionic

What a mvn -X give you? Any more clues. – Pontiac

-X details added above. – Ionic

Answer 1

Provided the parent version has been built before, this syntax (with the square brackets around the version number) allows to force a version which is not the latest:

mvn versions:update-parent -DallowSnapshots -DgenerateBackupPoms=false -DparentVersion="[7.0.11]" 

But the parent has to be built before maven makes the update. Otherwise it will ignore the specified version.

Fulmar

Interesting, more precise than my answer. +1 – Pontiac

@Pontiac Not sure if you are being sarcastic or not :). The stumble point was the set of square brackets around the version, in addition to the "built before" requirement. Without those square brackets, the version was ignored if it wasn't the latest. I can give you the bounty, if you want. – Ionic

No, I was not sarcastic, and the +1 was sincere. I missed the squared brackets. – Pontiac

Thank you for the time you spent. Sent you the bounty. – Ionic

Thank you. I have edited my answer to reference maven.apache.org/enforcer/enforcer-rules/versionRanges.html, which can be relevant here. – Pontiac

It looks like both the old and new versions of the parent need to be built and installed. When I tried to change from 0.0.2 to 0.0.3-SNAPSHOT, where the later was already built and installed in the local repo, mvn was complaining about not finding 0.0.2. – Vintner

Consider my case where using square brackets around the version still did not produce the desired version change. Local maven repo has 2 versions: 0.0 and 0.0.0. Changing the parent pom of a maven project from 0.0 to 0.0.0 only worked when I reverse the order of the <version> tags in [maven-repo-local]/[parent-pom]/maven-metadata-local.xml, that is, having <version>0.0.0</version> on top of <version>0.0</version>. I am wondering why maven tries to be smart in choosing the "latest" version for me instead of setting it to 0.0.0 as i tell it to with -DparentVersion="[0.0.0]" – Vintage

Answer 2

because the version I want to use is a version which is either locally built

Then the step which build the parent should not be just mvn clean build, but mvn clean install: that would cache the artifact in the Jenkins agent local maven cache.

either a version which will be built later

Then your job should have a preliminary step building and installing that new parent version, before your current step calling mvn versions:update-parent.

As the OP comments though:

The stumble point was the set of square brackets around the version, in addition to the "built before" requirement.
Without those square brackets, the version was ignored if it wasn't the latest.

See more at "Version Range Specification"

[1.0]   x == 1.0

Pontiac

I already do the maven clan install part, but that does not seem to be taken into account by maven, only the nexus repository. – Ionic

@FrédéricDonckels Nexus is the artifactory repository you can push to, with mvn deploy. But before deploy, you can chain multiple step doing only install: as long as they are part of the same job, executed on the same agent with the same user, the ~/.m2/repository local cache will store the artifact built. – Pontiac

I rephrased the whole question to provide more insight on the context and the tested scenarios – Ionic

Answer 3

If you want to set exactly version without any calculation from the plugin use skipResoultion parameter with the current version of the plugin:

mvn org.codehaus.mojo:versions-maven-plugin:2.17.1:update-parent -DallowSnapshots -DskipResolution=true -DparentVersion="your-version"

Prairie