|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [mojo-dev] [jira] (MVERSIONS-131) versions:set is ... JIRA
- [mojo-dev] [jira] (MVERSIONS-131) versions:se... Stephen Connolly (JIRA)
- [mojo-dev] [jira] (MVERSIONS-131) versions:se... Stephen Connolly (JIRA)
- [mojo-dev] [jira] (MVERSIONS-131) versions:se... JIRA
- [mojo-dev] [jira] (MVERSIONS-131) versions:se... Stephen Connolly (JIRA)

First, keep in mind that there is http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html#updateMatchingVersions which defaults to true
Second what matters about the change initiator is the effect of changing its version on the downstream builds.
So it doesn't matter if you change the groupId of B from its inherited, or change the artifactId from inherited or not. What matters is that you have not actually specified a <version>> tag at xpath:/project/version so that the Maven model uses the inherited version from the parent. Thus if the parent's version is changed the child's version must change also.
I am not entirely happy with the default behaviour being lax, e.g. updateMatchingVersions=true but the plugin was maintaining legacy behaviour so the "strict" mode is something that you need to turn on