[mojo-dev] [jira] (MVERSIONS-131) versions:set is not propagated to submodules if they don't inherit aggregator pom

Wed, 07 Aug 2013 02:13:26 -0700

Based on the specified change initiator: groupId:artifactId:oldVersion->newVersion it looks to see if that change has knock-on side-effects... so if the project being changed is used as a parent for other project and those child projects do not explicitly specify a xpath:/project/version and instead rely on inheritance from xpath:/project/parent/version then those child projects are added to the list of changes.

I'm mitigated about this statements :

  • This is not completely exact : if B specifies a xpath:/project/version which is the same as its parent, it will be taken into account (this is the case in the sample I have attached : B's version is specified to the same as A's version, and B is concerned by the version update)
  • If B had overriden its groupId (by not using its parent's), B is still taken into account (the simple fact that B inherit from a concerned artefact makes it concerned, even if its groupId doesn't match the -DgroupId=...)
  • Worst : if I create a B submodule named B2, and I change B's groupId, resulting in something like this : 
      + org.apache.maven.plugins.versions.versions-set-module-problem:A:0.1-SNAPSHOT without parent
  |
  +-+ a.new.groupId:B:0.1-SNAPSHOT with parent org.apache.maven.plugins.versions.versions-set-module-problem:A:0.1-SNAPSHOT
  | |
  | +- a.new.groupId:B2:0.1-SNAPSHOT with parent a.new.groupId:B:0.1-SNAPSHOT
  |
  +-- org.apache.maven.plugins.versions.versions-set-module-problem:C:0.1-SNAPSHOT without parent

    In that case, B2 will be concerned by the version update, whereas it doesn't have any matching groupId (as B) nor has a parent matching concerned GAV (it only has a grandparent concerned by the matching GAV)




To my POV, these are weird behaviours if I strictly conform to the spec.



I'm not saying these are bugs, I'm just saying that the spec could be interpreted differently.



In my case :


    
	
  • I don't think the enhancement you proposed is a good idea, and I previously exposed why : using wildcard for -DgroupId wouldn't be comprehensive (to my POV) because today already, a module not matching the target groupId could be concerned by the versions update
    • 
	
  • In my sample, the C project has already a DgroupId which matches exactly the A's groupId. What is making it different than B (in terms of effective-pom, since you're saying you're relying on a given groupId:artifactId:oldVersion>newVersion) ? For me : nothing.
    
  The only fact that B has A as its parent makes it concerned by the version change => It doesn't fit any GAV reasoning (see the B2 previous example) and doesn't seem natural at all.
    • 





Or maybe I missed something...
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
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Reply via email to