maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans-Peter Störr (JIRA) <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (MNG-624) automatic parent versioning
Date Fri, 02 Oct 2009 19:19:06 GMT

    [ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=193219#action_193219
] 

Hans-Peter Störr edited comment on MNG-624 at 10/2/09 2:17 PM:
---------------------------------------------------------------

Brian: We also have had about a dozen parent pom changes so far, but this is still an annoying
problem. (It might also be much worse if you do an agile project, turning out bi-weekly releases
for years.) 
The parent is actually intern to our multi module build. Perhaps a small example:

project/pom.xml          - aggregator for the parent, module1, module2
project/parent/pom.xml   - contains dependencyManagement etc.
project/module1/pom.xml
project/module2/pom.xml

If you switch the version number, you should need to change only one pom.xml. Right now you
have to change all 4, or in our case, all 300.

As I said: the problem is not the work of changing the poms - this is easily done by script
- but some annoying consequences of this unnecessary change. These might in part be because
of our particular set-up, but the number of votes and watchers shows we are not the only ones
who feel the pain. So why not allow to omit the version numbers at all if the parent of a
sub-module can be accessed by relative path? No harm is done for those who want to do it otherwise.



      was (Author: hstoerr):
    Brian: The parent is actually intern to our multi module build. The problem is also not
the churn of the parent, but the needless churn of our all the other poms after each release.
Perhaps a small example:

project/pom.xml          - aggregator for the parent, module1, module2
project/parent/pom.xml   - contains dependencyManagement etc.
project/module1/pom.xml
project/module2/pom.xml

If you switch the version number, you should need to change only one pom.xml. Right now you
have to change all 4, or in our case, all 300.

As I said: the problem is not the work of changing the poms - this is easily done by script
- but some annoying consequences of this unnecessary change. These might in part be because
of our particular set-up, but the number of votes and watchers shows we are not the only ones
who feel the pain. So why not allow to omit the version numbers at all if the parent of a
sub-module can be accessed by relative path? No harm is done for those who want to do it otherwise.


  
> automatic parent versioning
> ---------------------------
>
>                 Key: MNG-624
>                 URL: http://jira.codehaus.org/browse/MNG-624
>             Project: Maven 2
>          Issue Type: Improvement
>          Components: Inheritance and Interpolation
>            Reporter: Brett Porter
>            Assignee: Ralph Goers
>            Priority: Blocker
>             Fix For: 2.x
>
>         Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> (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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message