Details

    • Number of attachments :
      2

      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.

        Issue Links

          Activity

          Hide
          Adrian Shum added a comment - - edited

          For all suggestion/workaround proposed here using a property for parent version, they all suffer from one issue: This will work for build, but will fail on using the result as dependency.

          Assuming I have a very simple structure like this:

          foo-parent
          foo-lib
          

          assume the POm of foo-lib contains

              <parent>
                  <groupId>foo</groupId>
                  <artifactId>foo-parent</artifactId>
                  <version>${foo.version}</version>
                  <relativePath>../foo-parent/pom.xml</relativePath>
              </parent>
          

          (foo.version can be provided by any means, by command line or by property defined in parent etc)

          Because Maven is deploying/installing the POM as-is. That means, if I put foo-lib in the repository, when people is using it as dependency, the POM is containing only

          ${foo.version} 

          string literal as the parent version. There is no way that it can resolve the correct parent POM to refer to.

          May I suggests, instead of deploying the POM as-is, we are creating an "effective" POM to use to deploy? In the "effective" POM, we have all necessary properties replaced and use that for install/deploy.

          Show
          Adrian Shum added a comment - - edited For all suggestion/workaround proposed here using a property for parent version, they all suffer from one issue: This will work for build, but will fail on using the result as dependency. Assuming I have a very simple structure like this: foo-parent foo-lib assume the POm of foo-lib contains <parent> <groupId>foo</groupId> <artifactId>foo-parent</artifactId> <version>${foo.version}</version> <relativePath>../foo-parent/pom.xml</relativePath> </parent> (foo.version can be provided by any means, by command line or by property defined in parent etc) Because Maven is deploying/installing the POM as-is. That means, if I put foo-lib in the repository, when people is using it as dependency, the POM is containing only ${foo.version} string literal as the parent version. There is no way that it can resolve the correct parent POM to refer to. May I suggests, instead of deploying the POM as-is, we are creating an "effective" POM to use to deploy? In the "effective" POM, we have all necessary properties replaced and use that for install/deploy.
          Hide
          Stanilslav Spiridonov added a comment -

          I suggested it 2 years ago (https://jira.codehaus.org/browse/MNG-624?focusedCommentId=287554&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287554)

          Anyway I completely agree with you. Deploying the effective POM will not solve the whole issue, but will allow to separate the parent issue on independent parts and solve at least the deployment. I think it will be a right step

          Show
          Stanilslav Spiridonov added a comment - I suggested it 2 years ago ( https://jira.codehaus.org/browse/MNG-624?focusedCommentId=287554&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287554 ) Anyway I completely agree with you. Deploying the effective POM will not solve the whole issue, but will allow to separate the parent issue on independent parts and solve at least the deployment. I think it will be a right step
          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/

            People

            • Assignee:
              Unassigned
              Reporter:
              Brett Porter
            • Votes:
              313 Vote for this issue
              Watchers:
              222 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