[jira] Issue Comment Edited: (MNG-624) automatic parent versioning

["James Selvakumar (JIRA)" <ji...@codehaus.org>]

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

James Selvakumar edited comment on MNG-624 at 11/12/10 3:40 AM:
----------------------------------------------------------------

Since *support for profiles.xml might be removed* in future versions (Ref: [#MNG-4060]) (or was it removed already?), I'm proposing another workaround for the desperate hearts. This makes use of the "relativePath" attribute of parent.

NOTE: This has the same drawback as using profiles.xml, but it might help some of you.

This example assumes you have the following directory structure:

{code:none}
 - pom.xml
   - yourapp-child-a
     - pom.xml
   - yourapp-child-b
     - pom.xml
{code}

Define your parent pom's version as "FIXED" and define a custom version property.

{code:none}
 <project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.yourapp</groupId>
    <artifactId>yourapp-parent</artifactId>
    <packaging>pom</packaging>
    <version>FIXED</version>

    <properties>
     <yourapp.version>1.0-SNAPSHOT</yourapp.version>
    </properties>
 </project>
{code} 

And now the pom for "child-a" would look like the following:

{code:none}
 <project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.yourapp</groupId>
    <artifactId>yourapp-child-a</artifactId>
    <packaging>jar</packaging>
    <version>${yourapp.version}</version>

    <parent>
        <groupId>org.yourapp</groupId>
        <artifactId>yourapp-parent</artifactId>
        <version>FIXED</version>        
        <relativePath>..</relativePath>
    </parent>
 </project> 
{code} 

Same logic applies for "child-b" as well.

*Requirements*: 
For the above suggestion to work, your parent pom and modules should be in a single repository

*Advantage*: 
This would effectively let you define your version in only the parent 

*Disadvantage*:
Modules defined like this cannot be used as "libraries" in other modules that live in a separate repository because of [#MNG-2971]

      was (Author: sskjames):
    Since *support for profiles.xml* might be removed in future versions [#MNG-4060]( (or was it removed already?), I'm proposing another workaround for the desperate hearts. This makes use of the "relativePath" attribute of parent.

NOTE: This has the same drawback as using profiles.xml, but it might help some of you.

This example assumes you have the following directory structure:

{code:none}
 - pom.xml
   - yourapp-child-a
     - pom.xml
   - yourapp-child-b
     - pom.xml
{code}

Define your parent pom's version as "FIXED" and define a custom version property.

{code:none}
 <project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.yourapp</groupId>
    <artifactId>yourapp-parent</artifactId>
    <packaging>pom</packaging>
    <version>FIXED</version>

    <properties>
     <yourapp.version>1.0-SNAPSHOT</yourapp.version>
    </properties>
 </project>
{code} 

And now the pom for "child-a" would look like the following:

{code:none}
 <project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.yourapp</groupId>
    <artifactId>yourapp-child-a</artifactId>
    <packaging>jar</packaging>
    <version>${yourapp.version}</version>

    <parent>
        <groupId>org.yourapp</groupId>
        <artifactId>yourapp-parent</artifactId>
        <version>FIXED</version>        
        <relativePath>..</relativePath>
    </parent>
 </project> 
{code} 

Same logic applies for "child-b" as well.

*Requirements*: 
For the above suggestion to work, your parent pom and modules should be in a single repository

*Advantage*: 
This would effectively let you define your version in only the parent 

*Disadvantage*:
Modules defined like this cannot be used as "libraries" in other modules that live in a separate repository because of [#MNG-2971]
  
> automatic parent versioning
> ---------------------------
>
>                 Key: MNG-624
>                 URL: http://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 contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira