[ 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