[ 
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

        

Reply via email to