updateVersion goal modifies the parent version instead of the current pom

[pvigliatore]

When running the updateVersion goal on a pom with a <parent /> element, the <version /> tag of the parent is updated instead of the current pom

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/38038247-updateversion-goal-modifies-the-parent-version-instead-of-the-current-pom?utm_campaign=plugin&utm_content=tracker%2F19627210&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F19627210&utm_medium=issues&utm_source=github).

[jan-molak]

Hey @pvigliatore and thanks for reporting this, could you please create a test case to demonstrate the issue?

Many thanks, Jan

[timeapen]

One of our team members will write a failing IT shortly. In the meantime, it seems as if the cause of this bug is a parent pom that has submodules, one of which itself has a pom packaging type.

[jan-molak]

Thanks for the update, @timeapen, that's interesting! A failing test would definitely help, thank you.

J

[timeapen]

@jan-molak, @pvigliatore , failing test case here

You can see the build output here

There is really no guarantee that the pom that a project inherits from is on the same release cycle. For example, I believe that in Paolo's case we were inheriting from a pom in a separate project repository, that would have a different life-cycle than the child.

[jan-molak]

Thanks @timeapen that was fast! I think you're right regarding the cycle, but I'm not sure how much time I'll have this week to look into this. If anyone would like to take a stab at the pull request I'd be more than happy to review it and merge it in?

[timeapen]

@pvigliatore what was your work-around?

[pvigliatore]

@timeapen to work around the issue I separated the aggregator pom from the super pom. The aggregator pom is totally bare except for the <modules /> declaration.

This worked when I ran mvn release-candidate:updateVersion directly on my machine, however my automated build still updates the version number on the parent instead of the current pom. Not sure why the behavior differs between environments

[timeapen]

@pvigliatore, I wonder if on the build machine, the old poms are being cached in the .m2 repository? Maybe try blowing them away. Unless your fix included a release of the aggregator and super poms, how would the build now to grab the new ones?

[timeapen]

@jan-molak, any suggestions on what the correct fix would be? Can you think of a way to conclusively determine whether the parent pom version should change as part of a CD deployment?

[timeapen]

Maybe the solution is to only update the parent version in the case if aggregation and not in the case of inheritance?

[jan-molak]

Hmm, that's an interesting idea. Although one could use a parent pom to only define shared properties and not the modules, yet still like to update its version - see #14 and the associated test case. I'm not sure how we'd be able to satisfy that condition?

[jan-molak]

Closing this issue as stale. If you still need this functionality, please feel free to reopen it.