You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Robert Simmons Jr. (JIRA)" <ji...@codehaus.org> on 2009/11/12 22:02:56 UTC

[jira] Commented: (MNG-624) automatic parent versioning

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

Robert Simmons Jr. commented on MNG-624:
----------------------------------------

I would like to reiterate others points on this issue. Personally I think <relativePath> should be enough to specify a parent POM. I see many maven developers proselytizing about how projects should be created and how POMs should be maintained but the fact is that in an organization changing the entire process to suit Maven is not possible. The second fact is that one size or process doesnt fit all with projects.

I can think of a dozen examples where projects must stay in locked version with their parent. For example, a project consisting of a data layer, web layer, web service interface and EJBs will all form one cohesive release as a war. They must stay together in versions but they shouldn't have to be updating all 6 files (projects and parent pom) each time there is a version change. They should be able to state a single version number in a parent and use that. 

The thinking behind different versions for each project and super pom being separate is only one use case. That use case assumes all projects are more or less independent builds. This isnt the case with other projects. 

Using <relativePath> to specify "take version from the parent pom" is the best of both worlds as it allows both models and takes nothing away from anyone. That seems to be a much more practical way to go then shouting from the rooftops "NO YOU ARE DOING IT ALL WRONG, THROW OUT YOUR MILLIONS IN INVESTMENT AND REARCHITECT YOUR PROJECT OUR WAY." By shouting that, you are simply telling my boss "nah we will stick with ant" and that is counterproductive.

> 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