Details

    • Number of attachments :
      3

      Description

      (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521)

      currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them.

      One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects.

      This also introduces the need for tool support to populate the version on release and deployment for reproducibility.

      1. MNG-624-maven-2.0.x-r507648.patch
        41 kB
        Eric Brown
      2. MNG-624-tests.tar.gz
        7 kB
        Eric Brown

        Issue Links

          Activity

          Hide
          Eduardo Souza added a comment -

          Maybe this issues can partially correct this problem.

          https://jira.codehaus.org/browse/MNG-2971

          https://jira.codehaus.org/browse/MNG-4223

          They are to be reviewed for 3.x...

          Show
          Eduardo Souza added a comment - Maybe this issues can partially correct this problem. https://jira.codehaus.org/browse/MNG-2971 https://jira.codehaus.org/browse/MNG-4223 They are to be reviewed for 3.x...
          Hide
          Jörg Hohwiller added a comment -

          while this feature would be still desirable there is a workaround possible with consumer-maven-plugin:
          https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin
          Please note that the plugin will move out of sandbox in the future so try mojo instead of sandbox if the link stopped working:
          https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin

          What you can now do is keep all the versions of your parent POMs fixed and consider them as development artifacts that will not be relevant for end-users of your artifacts. If you use consumer-maven-plugin it will generate a "minified" POM with variables and dependencies resolved and without parent POM relation, etc. This allows you to define variables, dependency management, etc. in your parent POMs but bump the final GAV coordinates and dependencies of your child/leaf modules on install/deploy.

          Simply check-out and install this plugin. Then add this to your toplevel POMs build-section:
          <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>consumer-maven-plugin</artifactId>
          <version>1.0.0-beta-1-SNAPSHOT</version>
          </plugin>

          I hope that the plugin will move out of sandbox and be released soon.

          If you have any feedback please let us know (ideally on MOJOs dev mailing list).

          Show
          Jörg Hohwiller added a comment - while this feature would be still desirable there is a workaround possible with consumer-maven-plugin: https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin Please note that the plugin will move out of sandbox in the future so try mojo instead of sandbox if the link stopped working: https://svn.codehaus.org/mojo/trunk/mojo/consumer-maven-plugin What you can now do is keep all the versions of your parent POMs fixed and consider them as development artifacts that will not be relevant for end-users of your artifacts. If you use consumer-maven-plugin it will generate a "minified" POM with variables and dependencies resolved and without parent POM relation, etc. This allows you to define variables, dependency management, etc. in your parent POMs but bump the final GAV coordinates and dependencies of your child/leaf modules on install/deploy. Simply check-out and install this plugin. Then add this to your toplevel POMs build-section: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>consumer-maven-plugin</artifactId> <version>1.0.0-beta-1-SNAPSHOT</version> </plugin> I hope that the plugin will move out of sandbox and be released soon. If you have any feedback please let us know (ideally on MOJOs dev mailing list).
          Hide
          Jörg Hohwiller added a comment -
          Show
          Jörg Hohwiller added a comment - Plugin had to be renamed: http://mojo.codehaus.org/flatten-maven-plugin/
          Hide
          Jörg Hohwiller added a comment -

          For the workaround have a look here:
          http://mojo.codehaus.org/flatten-maven-plugin/examples/example-multiple-versions.html

          2nd release is out in central repo. Just add this to your top-level POM build section:

          <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>flatten-maven-plugin</artifactId>
          <version>1.0.0-beta-2</version>
          </plugin>

          Show
          Jörg Hohwiller added a comment - For the workaround have a look here: http://mojo.codehaus.org/flatten-maven-plugin/examples/example-multiple-versions.html 2nd release is out in central repo. Just add this to your top-level POM build section: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>flatten-maven-plugin</artifactId> <version>1.0.0-beta-2</version> </plugin>
          Hide
          Mark Morris added a comment - - edited

          If anyone's looking for a custom solution for this issue, we implemented a modification in-house that allows you to replace your pom.xml parent versions with a dynamic value. You basically drop an aaa-mgs-maven-overrides.jar into your apache-maven\lib directory which then intercepts the parent version right when it's read (and replaces it with a properties file value). You can take a look at the attached Maven_overrides_for_dynamic_parent_version_MGS.zip file for the details (and the jar) but here is everything at a high level (posted with permission from my director at Monster Government Solutions):

          1) Change your pom.xml parent versions to look like this (all our sub-projects use this):

          <parent>
          <groupId>com.monster.mgs.terra</groupId>
          <artifactId>terra-parent</artifactId>
          <version>$MGS

          {branch_configs/branch.properties#snapshot.version}

          </version>
          <relativePath>../../terra/terra-parent/pom.xml</relativePath>
          </parent>

          2) Create a single root-level branch_configs folder with a branch.properties file containing property snapshot.version=ABC-SNAPSHOT (these can be modified to your values)

          Now when you run any maven command, the custom code will detect the "$MGS{}" string and replace it with the value from your properties file. The overrides jar contains modified versions of the maven MavenXpp3Reader and MavenXpp3ReaderEx classes and replaces functionality in their getTrimmedValue(String) methods (which is called for almost every value in the poms). Theoretically this approach could be used in the actual maven source as a permanent implementation option but you'd want to use something more generic than "$MGS{}" and you'd probably want to pass in the pom.xml's file location (to reduce complexity, this overrides jar doesn't handle relative paths).

          There are also a couple other steps that are needed when using IntelliJ and Jenkins (these steps are detailed in the Dynamic_Parent_Version_MGS_Wiki_Page.pdf in the Maven_overrides_for_dynamic_parent_version_MGS.zip ). This approach got rid of all our merge headaches when merging between branches (with over 90 pom.xmls in sub-projects) so hopefully this will be useful to others as well. Also thanks in advance if this or something like it is put into the actual maven codebase.

          Thanks,
          Mark Morris.

          Show
          Mark Morris added a comment - - edited If anyone's looking for a custom solution for this issue, we implemented a modification in-house that allows you to replace your pom.xml parent versions with a dynamic value. You basically drop an aaa-mgs-maven-overrides.jar into your apache-maven\lib directory which then intercepts the parent version right when it's read (and replaces it with a properties file value). You can take a look at the attached Maven_overrides_for_dynamic_parent_version_MGS.zip file for the details (and the jar) but here is everything at a high level (posted with permission from my director at Monster Government Solutions): 1) Change your pom.xml parent versions to look like this (all our sub-projects use this): <parent> <groupId>com.monster.mgs.terra</groupId> <artifactId>terra-parent</artifactId> <version>$MGS {branch_configs/branch.properties#snapshot.version} </version> <relativePath>../../terra/terra-parent/pom.xml</relativePath> </parent> 2) Create a single root-level branch_configs folder with a branch.properties file containing property snapshot.version=ABC-SNAPSHOT (these can be modified to your values) Now when you run any maven command, the custom code will detect the "$MGS{}" string and replace it with the value from your properties file. The overrides jar contains modified versions of the maven MavenXpp3Reader and MavenXpp3ReaderEx classes and replaces functionality in their getTrimmedValue(String) methods (which is called for almost every value in the poms). Theoretically this approach could be used in the actual maven source as a permanent implementation option but you'd want to use something more generic than "$MGS{}" and you'd probably want to pass in the pom.xml's file location (to reduce complexity, this overrides jar doesn't handle relative paths). There are also a couple other steps that are needed when using IntelliJ and Jenkins (these steps are detailed in the Dynamic_Parent_Version_MGS_Wiki_Page.pdf in the Maven_overrides_for_dynamic_parent_version_MGS.zip ). This approach got rid of all our merge headaches when merging between branches (with over 90 pom.xmls in sub-projects) so hopefully this will be useful to others as well. Also thanks in advance if this or something like it is put into the actual maven codebase. Thanks, Mark Morris.

            People

            • Assignee:
              Unassigned
              Reporter:
              Brett Porter
            • Votes:
              320 Vote for this issue
              Watchers:
              229 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 4 hours
                4h
                Remaining:
                Remaining Estimate - 4 hours
                4h
                Logged:
                Time Spent - Not Specified
                Not Specified