[
http://jira.codehaus.org/browse/MNG-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210445#action_210445
]
Abhishekh Padmanbhan edited comment on MNG-2157 at 2/17/10 9:18 AM:
--------------------------------------------------------------------
I think I might have a workaround/solution to this problem using a profiles.xml
(MAVEN 2.1.0) in the root project that holds the project current version as a
property. This property then can be used as a value to the version in the
parent tag definition in all its sub modules.
Find below the workaround that I use to propagate the project version variable
as a property to all of the project submodule. By doing this I avoid having to
redefine the project parent pom version in all its submodules.
*PROJECT STRUCTURE (all caps are modules)*
ROOT
- pom.xml
- profiles.xml
- WAR
-- pom.xml
- EJB
-- pom.xml
*profiles.xml*
{noformat}
<profilesXml>
<profiles>
<profile>
<id>projectProfile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<currentVersion>1.0.1</currentVersion>
</properties>
</profile>
</profiles>
</profilesXml>
{noformat}
*ROOT/pom.xml*
{noformat}
<project>
<groupId>projGrp</groupId>
<artifactId>rootProjName</artifactId>
<version>${currentVersion}</version>
</project>
{noformat}
*ROOT/EJB/pom.xml*
{noformat}
<project>
<artifactId>ejbProjName</artifactId>
<packaging>ejb</packaging>
<parent>
<groupId>projGrp</groupId>
<artifactId>rootProjName</artifactId>
<version>${currentVersion}</version>
</parent>
</project>
{noformat}
I think this way the project version is a property just in one file
profiles.xml in the ROOT project and will be the only file that changes when
the version changes.
I have not tested this exhaustively but seems to work in principle.
was (Author: abhishekhp):
I think I might have a workaround/solution to this problem using a
profiles.xml in the root project that holds the project current version as a
property. This property then can be used as a value to the version in the
parent tag definition in all its sub modules.
Find below the workaround that I use to propagate the project version variable
as a property to all of the project submodule. By doing this I avoid having to
redefine the project parent pom version in all its submodules.
*PROJECT STRUCTURE (all caps are modules)*
ROOT
- pom.xml
- profiles.xml
- WAR
-- pom.xml
- EJB
-- pom.xml
*profiles.xml*
{noformat}
<profilesXml>
<profiles>
<profile>
<id>projectProfile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<currentVersion>1.0.1</currentVersion>
</properties>
</profile>
</profiles>
</profilesXml>
{noformat}
*ROOT/pom.xml*
{noformat}
<project>
<groupId>projGrp</groupId>
<artifactId>rootProjName</artifactId>
<version>${currentVersion}</version>
</project>
{noformat}
*ROOT/EJB/pom.xml*
{noformat}
<project>
<artifactId>ejbProjName</artifactId>
<packaging>ejb</packaging>
<parent>
<groupId>projGrp</groupId>
<artifactId>rootProjName</artifactId>
<version>${currentVersion}</version>
</parent>
</project>
{noformat}
I think this way the project version is a property just in one file
profiles.xml in the ROOT project and will be the only file that changes when
the version changes.
I have not tested this exhaustively but seems to work in principle.
> Properties defined in top-level profiles.xml do no propagate to child modules
> -----------------------------------------------------------------------------
>
> Key: MNG-2157
> URL: http://jira.codehaus.org/browse/MNG-2157
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
> Affects Versions: 2.0.2
> Reporter: Jason Dillon
> Assignee: Benjamin Bentmann
> Priority: Blocker
>
> I have a multi-module build, and at the top-level I have a profile called
> 'release-environment', which is activated by -Denv=release.
> I need the local release build to use different values for JDBC configuration
> to run integration tests, and defined them in a profiles.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <settings>
> <profiles>
> <profile>
> <id>local-release-environment</id>
> <activation>
> <property>
> <name>env</name>
> <value>release</value>
> </property>
> </activation>
>
> <properties>
> <jdbc.username>mif_jason</jdbc.username>
> <jdbc.password>mif_jason</jdbc.password>
> <jdbc.schema>MIF_JASON</jdbc.schema>
> </properties>
> </profile>
> </profiles>
>
> </settings>
> {code}
> My project looks like:
> pom.xml
> merchant/pom.xml
> merchant/core/pom.xml
> merchant/services/pom.xml
> If i put profiles.xml as a peer to pom.xml and run {{mvn clean install
> -Denv=release}} from the top-level, I get errors because the properties are
> not propagated to the merchant/core/pom.xml module.
> If I put profiles.xml as a peer to merchant/core/pom.xml and run {{mvn clean
> install -Denv=release}}, then it works as expected... properties are set as
> they are defined in profiles.xml.
> But, this is not manageable, as I need to set some properties for all of the
> modules in a multi-module build... But I don't want to use those properties
> for all Maven2 projects, so I can not really put it into ~/.m2/settings.xml
> I had expected that a top-level profiles.xml would work, but it does not. Is
> this by design, is there another recommend way to provide per-top-level
> multi-module project configuration on a local user basis (ie. no pom.xml
> modifications)?
--
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
