[
https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291110#comment-291110
]
Christian Lewold commented on MNG-624:
--------------------------------------
Andrew - I don't know if I understand you correct. If I do a "mvn clean
install" on my parent project, all the modules are installed in the local repo
with the correct property substituted.
But actually this is all a mess. I'm quite new to maven, but I'm not that
impressed right now, as such very basic things simply don't work. I mean face
it - maven claims it wants to reduce effort, and then people are forced to
update version numbers in ALL poms every time the version changes.
Up to now I found nothing which cannot be achieved by well written ant scripts
(central script containing the logic with small scripts importing the central
one).
Ok this particular problem seems to be solved with Maven 3.1 - a problem which
is like 7 years old, and where noone seems to know when 3.1 finally arrives
.....
Up to this point I try to live with the workaround, as I'm not in the mood to
change like 20 pom.xml files every time I change the version (yes, yes there is
the release plugin - but that's still just a workaround for a messy concept)
> automatic parent versioning
> ---------------------------
>
> Key: MNG-624
> URL: https://jira.codehaus.org/browse/MNG-624
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
> Reporter: Brett Porter
> Assignee: Ralph Goers
> Priority: Blocker
> Fix For: 3.1
>
> 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, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
