[
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
