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.