You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Karel Piwko (JIRA)" <ji...@codehaus.org> on 2011/07/07 17:55:43 UTC
[jira] Issue Comment Edited: (MNG-5127) CLONE - Maven profile
activation does not work when profile is defined in inherited 'parent' pom
[ https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272586#comment-272586 ]
Karel Piwko edited comment on MNG-5127 at 7/7/11 10:54 AM:
-----------------------------------------------------------
This behavior makes multi-module project testing/build a mess. See following example:
Parent(aggregator) pom.xml
{code}
<profile>
<id>linux-64bit</id>
<activation>
<property>
<name>arch</name>
<value>linux-64bit</value>
</property>
</activation>
<modules>
<module>lin-64</module>
<module>lin-64-support</module>
</modules>
<profile>
<id>linux-64bit-foo</id>
<activation>
<property>
<name>activation</name>
<value>linux-64bit-foo</value>
</property>
</activation>
<modules>
<module>lin-64-foo</module>
</modules>
</profile>
<profile>
<id>foo</id>
<activation>
<property>
<name>framework</name>
<value>foo</value>
</property>
</activation>
<modules>
<module>foo</module>
<module>foo-common</module>
</modules>
...other frameworks and archs...
</profile>
{code}
Then, every module might have a specific configuration, e.g.
foo/pom.xml:
{code}
<profile>
<id>linux-32bit</id>
...
</profile>
<profile>
<id>linux-64bit</id>
...
</profile>
{code}
Now, supposing I want to build framework foo on arch linux-64, I have to do
{code}
mvn -Pfoo,linux-64bit,linux-64bit-foo -Dframework=foo -Darch=linux-64 -Dactivation=linux-64-foo install
{code}
leading to many "profile does not exist" errors/warnings.
In ideal Maven world where profile activation is inherited, this would do the installation:
{code}
mvn -Dframework=foo -Darch=linux-64 -Dactivation=linux-64 install
{code}
If I stick with the latter, I would have to recopy the activation to every module where applicable. Then I'll get the build configuration from the parent.
If I stick with the former, I would have to remove activation by a property and enumerate all possible combination as -P activated profiles, ignoring warnings.
Neither of the approaches helps to manage a large project with a single aggregator.
Note: activation property is there due to http://jira.codehaus.org/browse/MNG-4565
was (Author: kapy):
This behavior makes multi-module project testing/build a mess. See following example:
Parent(aggregator) pom.xml
{code}
<profile>
<id>linux-64bit</id>
<activation>
<property>
<name>arch</name>
<value>linux-64bit</value>
</property>
</activation>
<modules>
<module>lin-64</module>
<module>lin-64-support</module>
</modules>
<profile>
<id>linux-64bit-foo</id>
<activation>
<property>
<name>activation</name>
<value>linux-64bit-foo</value>
</property>
</activation>
<modules>
<module>lin-64-foo</module>
</modules>
</profile>
<profile>
<id>foo</id>
<activation>
<property>
<name>framework</name>
<value>foo</value>
</property>
</activation>
<modules>
<module>foo</module>
<module>foo-common</module>
</modules>
...other frameworks and archs...
</profile>
{code}
Then, every module might have a specific configuration, e.g.
foo/pom.xml:
{code}
<profile>
<id>linux-32bit</id>
...
</profile>
<profile>
<id>linux-64bit</id>
...
</profile>
{code}
Now, supposing I want to build framework foo on arch linux-64, I have to do
mvn -Pfoo,linux-64bit,linux-64bit-foo -Dframework=foo -Darch=linux-64 -Dactivation=linux-64-foo install
leading to many "profile does not exist" errors/warnings.
In ideal Maven world where profile activation is inherited, this would do the installation:
mvn -Dframework=foo -Darch=linux-64 -Dactivation=linux-64 install
If I stick with the latter, I would have to recopy the activation to every module where applicable. Then I'll get the configuration from the parent.
If I stick with the former, I would have to remove activation by a property and enumerate all possible combination as -P activated profiles, ignoring warnings.
Neither of the approaches helps to manage a large project with a single aggregator.
Note: activation property is there due to http://jira.codehaus.org/browse/MNG-4565
> CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
> ------------------------------------------------------------------------------------------------
>
> Key: MNG-5127
> URL: https://jira.codehaus.org/browse/MNG-5127
> Project: Maven 2 & 3
> Issue Type: Bug
> Reporter: Gilles Scokart
> Assignee: John Casey
>
> The goal is to activate a maven profile based on OS user name.
> When I create a standalone project with a profile activation, it works,
> however, when I define the profile in a "parent" pom, it is never activated.
> this works:
> ...
> <profile>
> <id>TONY</id>
> <activation>
> <property>
> <name>user.name</name>
> <value>WINTONY</value>
> </property>
> </activation>
> <properties>
> </properties>
>
> So in this case, my profile is activated based on my OS user name
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building Proj1
> [INFO] task-segment: [help:active-profiles] (aggregator-style)
> [INFO] ----------------------------------------------------------------------------
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2':
> The following profiles are active:
> - TONY (source: pom)
> ------------------
> However, if I now have the profiles definition in the "parent" pom, it doesn't work when I build a child project
> So the child project references the parent pom containing the profiles and the activation, but when it is built,
> the profile is not activated
> PARENT POM:
> ...
> <profiles>
> <profile>
> <id>TONY</id>
> <activation>
> <property>
> <name>user.name</name>
> <value>WINTONY</value>
> </property>
> </activation>
> <properties>
> ...
> CHILD POM (the one being built)
> <project>
> <parent>
> <groupId>com.capgemini.be.proj1</groupId>
> <artifactId>parent</artifactId>
> <version>4.0.2</version>
> </parent>
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building Proj1 Application
> [INFO] task-segment: [help:active-profiles] (aggregator-style)
> [INFO] ----------------------------------------------------------------------------
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2':
> There are no active profiles.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira