Mojo's Versions Maven Plugin
  1. Mojo's Versions Maven Plugin
  2. MVERSIONS-131

versions:set is not propagated to submodules if they don't inherit aggregator pom

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: 1.1, 1.2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Maven 2.2.1
    • Number of attachments :
      2

      Description

      If we have a project A with modules B & C where :

      • B inherit from A
      • C DOESN'T inherit from A

      When we execute the following command line :
      mvn org.codehaus.mojo:versions-maven-plugin:1.2:set -DnewVersion=0.1

      Only A & B are updated.
      The fact that C doesn't inherit from A (whereas C is a module of A) doesn't make it updated.

      1. MVERSIONS-131_patch.txt
        7 kB
        Daniel Johnson

        Issue Links

          Activity

          Hide
          Daniel Johnson added a comment -

          This has been a long standing problem for me as well. Has anyone been able to find a work-around? It does not make sense to me why this only works when the children specify the aggregator/reactor as the parent POM. Curious if it is a limitation, or a missed corner case in the code.

          Show
          Daniel Johnson added a comment - This has been a long standing problem for me as well. Has anyone been able to find a work-around? It does not make sense to me why this only works when the children specify the aggregator/reactor as the parent POM. Curious if it is a limitation, or a missed corner case in the code.
          Hide
          Daniel Johnson added a comment - - edited

          Here is a proposed patch MVERSIONS-131_patch.txt. The change is to simply update all projects which had the same version to start with as the reactor/aggregator POM. If the reactor/aggregator POM is the <parent> the parent version is also updated as before, but essentially it simplifies the logic by just updating all projects with the same version instead of only those projects where the parent was the reactor.

          All unit tests still pass with this patch, but I did not check what the unit tests are actually testing...

          Show
          Daniel Johnson added a comment - - edited Here is a proposed patch MVERSIONS-131_patch.txt . The change is to simply update all projects which had the same version to start with as the reactor/aggregator POM. If the reactor/aggregator POM is the <parent> the parent version is also updated as before, but essentially it simplifies the logic by just updating all projects with the same version instead of only those projects where the parent was the reactor. All unit tests still pass with this patch, but I did not check what the unit tests are actually testing...
          Hide
          Fernando Padilla added a comment -

          Yes, this is hitting me right now and would love to get this fixed!

          Show
          Fernando Padilla added a comment - Yes, this is hitting me right now and would love to get this fixed!
          Hide
          Michal Kroliczek added a comment -

          Oh i spent couple hours on that, event prepared test case and then found it
          Please fix it.

          Show
          Michal Kroliczek added a comment - Oh i spent couple hours on that, event prepared test case and then found it Please fix it.
          Hide
          Frank Schönheit added a comment -

          could any of the (core) developers please common whether

          • this is an accepted bug (i.e. intended to be fixed)
          • the attached patch is a legitimate and viable solution
          • there are any plans in which version this might be fixed?

          (We're in need of this feature, too, and I'm trying to get a feeling how far we are from getting it )

          Thanks.

          Show
          Frank Schönheit added a comment - could any of the (core) developers please common whether this is an accepted bug (i.e. intended to be fixed) the attached patch is a legitimate and viable solution there are any plans in which version this might be fixed? (We're in need of this feature, too, and I'm trying to get a feeling how far we are from getting it ) Thanks.
          Hide
          Stephen Connolly added a comment - - edited

          This is functioning as designed.

          The goal is designed to update the version of the specified project (i.e. by -DgroupId=... -DartifactId=... -DoldVersion=... or picking up the defaults from the aggregator root, a.k.a. the project in the current working directory or the project referenced by -f) and ripple that change and any consequent changes through the largest effective reactor that can be constructed from the current reactor.

          The reactor is expanded by looking in the reactor root's parent directory for a pom.xml that has a <module> that points back to the project... this lets us discover the whole "effective" structure of pom.xml files to evaluate the scope of the change.

          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.

          Once the list of GAV changes is complete, the plugin then checks all the <dependency> references to see if they match any of the oldVersion's used in the final list of GAV changes, in which case they are changed to the newVersion

          What would be a valid enhancement (if I didn't implement it already) would be to allow the use of wildcards in the groupId or artifactId. With such a feature the end-outcome you desire could be achieved by running, e.g. mvn versions:set "-DgroupId=*" "-DartifactId=*" "-DoldVersion=*" -DnewVersion=2.1-SNAPSHOT but a separate ticket should be opened for such an enhancement.

          Show
          Stephen Connolly added a comment - - edited This is functioning as designed. The goal is designed to update the version of the specified project (i.e. by -DgroupId=... -DartifactId=... -DoldVersion=... or picking up the defaults from the aggregator root, a.k.a. the project in the current working directory or the project referenced by -f ) and ripple that change and any consequent changes through the largest effective reactor that can be constructed from the current reactor. The reactor is expanded by looking in the reactor root's parent directory for a pom.xml that has a <module> that points back to the project... this lets us discover the whole "effective" structure of pom.xml files to evaluate the scope of the change. 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. Once the list of GAV changes is complete, the plugin then checks all the <dependency> references to see if they match any of the oldVersion 's used in the final list of GAV changes, in which case they are changed to the newVersion What would be a valid enhancement (if I didn't implement it already) would be to allow the use of wildcards in the groupId or artifactId . With such a feature the end-outcome you desire could be achieved by running, e.g. mvn versions:set "-DgroupId=*" "-DartifactId=*" "-DoldVersion=*" -DnewVersion=2.1-SNAPSHOT but a separate ticket should be opened for such an enhancement.
          Hide
          Frédéric Camblor added a comment -

          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...

          Show
          Frédéric Camblor added a comment - 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...
          Hide
          Stephen Connolly added a comment -

          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

          Show
          Stephen Connolly added a comment - 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

            People

            • Assignee:
              Unassigned
              Reporter:
              Frédéric Camblor
            • Votes:
              6 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: