Different profile used for versions:set and versions:revert .

[garretwilson]

I have an aggregate POM situation that does not use inheritance, i.e the aggregated POMs do not have a parent-child relationship with the aggregating POM. The directory structure looks like this:

• aggregate/
• foo/
• bar/

The aggregating POM in the aggregate/ directory specifies the foo module:

	<modules>
		<module>../foo</module>

It also has a profile foobar which brings in the bar module:

	<profiles>
		<profile>
			<id>foobar</id>
			<modules>
				<module>../bar</module>
			</modules>
		</profile>

Now here's the interesting part. If I go into the aggregate/ directory and issue the following command:

mvn versions:set -DnewVersion=1.2.3 -DprocessAllModules

Thanks to the processAllModules option, this updates the aggregate POM version and the aggregated module versions both (both foo and bar, as well as there interdependent dependency references)! Yay!

But if I then try to revert the changes:

mvn versions:revert -DprocessAllModules

This command does not revert the POM for the bar module!!! I have to specify the foobar profile to get it to be reverted too:

mvn versions:revert -DprocessAllModules -P foobar

One can make arguments either way about whether the plugin should automatically process modules that are part of profiles that weren't indicated, and for the purposes of this ticket it really doesn't matter.

The important thing is that: shouldn't both goals versions:set and versions:revert use the same module inclusion rules for the processAllModules option? Put another way, shouldn't I be able to use the same options I used for changing the version to commit or revert that version? I don't understand what different semantics of processAllModules would require me to indicate a profile for one of the goals but not the other.

[Pirayya]

I get the exact same issue in one of my projects (writing this comment just to "bump" the issue). I think versions:revert and versions:set should have the same behaviour and alter the same modules!

[andrzejj0]

Looking into it. I know it's an old one.

[andrzejj0]

RevertMojo only recovers the old copy of the root pom.xml from the backup in the .versionsBackup file en relies on Maven itself to process all files in the reactor. This could indeed be enhanced.