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.

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>
...

It's closed, because it behaves as designed. Profiles are always valid in the scope of the POM they are defined in, they are not inherited. The help plugin does unfortunately only show active profiles of the *current* POM, but not the ones of the parent. You have to repeat the activation for he current POM, otherwise the profile will not be active.

In my [grand]-parent pom, I have a profile always active. When I run in my sub-prjoect mvn help:all-profiles, I see the profile as being inactive. But if I run the build, the plugin of my profile are being executed.

However, if I specify an other profile with -P on the comand line, the 'always' active profile is not active anymore.

I'm not sure anymore what is feature and what is not. I think there is at least an issue in the help plugin. If the plugin defined in the profile will be executed, I think they should be listed as active.

The other (maybe as designed) issue is that providing a profile with -P disable the profile supposed to be always active.

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.

Is there a final statement on this?
If think it clear that some kind of inheritance is needed for profiles - for me, at least the activation of a profile must be inherited to the childs.
Having only the '-PmyProfile1,myProfile2' switch is not acceptable if one needs to have multiple combinations of profiles.

What do you think about adding a new commandline option to allow this? e.g.:

$> mvn -inheritProfileActivation

This way I could activate multiple profiles with a single property, without redefining the activation in each child pom.xml

$> mvn -inheritProfileActivation -DmyProfileSet

And if possible, I would even like to define 'inheritProfileActivation' in the parent pom, so a user would not have to define it at all. To not have to change the schema of the POM, we could use a property like:
"project.inheritProfileActivation" which could be reused in a future POM change as a tag. (same way as for 'sourceEncoding': http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding)

wdyt? I would spend time to implement this, but would this be accepted?

I think the requirement here is to be able to:
- Define only once, what is a boy, what is a girl, and what is a kid.
- Apply those "labels" to modules and make them *stick*, so that there's no need to use command line parameters.

It seems to me that this should be the main goal of maven profiles.
This unimplemented feature really gets in the way of good, DRY configuration and build management for big modular projects.

Description:
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.

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
{code:xml|title=PARENT POM}
...
<profiles>
<profile>
<id>TONY</id>
<activation>
<property>
<name>user.name</name>
<value>WINTONY</value>
</property>
</activation>
<properties>
...
{code}

was:
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.

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>
...