Maven profile activation does not work when profile is defined in inherited 'parent' pom

I fear "this behavior is by design". According to John Casey's post at http://www.nabble.com/Profile-inheritance-tf2953156s177.html#a8260582 and some docs at http://docs.codehaus.org/display/MAVEN/Build+Profiles, profiles by themselves are not inherited at all but only their effects after being applied to the POM. Now, when a profile is not inherited, its activation is not inherited, neither.

Nevertheless, I would consider profile inheritance useful, too. To name a further use-case, imagine one wants to overwrite certain aspects of a profile for a module POM that inherits from a parent POM. For example, slightly change a plugin configuration that is inherited when the profile is activated. Currently, one needs to redefine the <activation> element in the module POM for such a thing to work. But as we all know, copy&paste is bad.

the profile itself can be used from the parent pom, thus strictly speaking, it is inherited, although it can not be overridden (which would be a very nice feature, I aree, since a lot of profiles have only a few different properties)

=> the profile in the parent pom can be "used", but not through activation keys, only with "-P" parameter to maven

Seems this behaviour is present only in Windows. When using Maven profiles with activation keys in Mac OS X, Solaris, or any other *NIX, it works as expected (of course, you still have to run MVN from the same dir the parent pom is located in).

how can it be OS dependent. ?
The scenario works fine for a simple maven project without 'parent'. The activation keys work fine
Only in the 'parent' child scenario it does not work.

The goal is to have all profiles defined in the parent pom, and every child pom inherits this pom.
We don't want to put all properties in every pom, this is the reason for existence of the parent pom

I can confirm this problem still exists in Maven 2.1.0-M1. Any chance of it being fixed in M2?

see test attachment in MNG-3897

This really isn't a bug in Maven. If anything, it's a minor documentation in the help plugin. The profile is activated, it's just not an active profile for the current project, so it doesn't appear in the list of active profiles. But if you were to run help:effective-pom, you would see that the profile has take effect.

Consolidating to 2.1.0-M1 so we can then rename to 2.1.0. We can weed out any issues we want to push to a later release from this set once we've done the consolidation.

I've tried this with Maven 2.1.0-SNAPSHOT (used to be 2.1.0-M2-SNAPSHOT) on OS X and Windows, using a modified version of the test in the linked issue. I added a profile to the parent to duplicate the user.name trigger, and modified the relativePath of the parent entry in the child POM so it can't traverse that link to reach the parent POM. Then, I installed the parent POM into the local repository, and ran help:active-profiles (from help plugin 2.0.2) on the child. It showed the user.name triggered profile as active.

BTW, I also tried this without a modified relativePath, and it worked. I also ran from the parent POM, and it showed as active in both the parent and the child.

If you can supply a failing test case and detailed instructions to reproduce this error, we can reopen it.

I have a similar problem with maven 2.1.0. The activation of the profile in the parent pom is defined as follows <activation><file><exists>$

/java</exists></file></activation>. Because my pom-packaged project has no src/main/java-folder the profile is not activated and it stays deactivated for modules too, even if the module has such folder!

I have made the following observations with Maven 2.2.1.

I have three poms, a parent, a child, and an aggregator. The aggregator includes the child directly as a module, but not the parent. The parent is the parent POM of the child. I am running the build with "mvn clean install" on the aggregator.

I wrote a profile with a configuration of some plugins that are usually not applied within my project hierarchy, i.e. the occurrences of these plugins in the profile defined in the parent POM are the only ones. Therefore, when I run my build, I can easily see if the profile is in effect, since I can see whether not not the extra plugins were executed.

In the following constellations, the profile was active during the build:

1.1 Activation via System Property defined in the parent. Profile not mentioned in the child at all. System Property set on the console. In this case however, the profile would also be active when building only the parent itself, an unwanted effect.

1.2 Same activation via System Property defined in the parent and in the child. System Property set on the console. In this case however, the profile would also be active when building only the parent itself, an unwanted effect.

1.3 No explicit activation defined in the parent nor the child. Profile not mentioned in the child at all. Profile included in activeProfiles in settings.xml. In this case however, the profile would also be active when building only the parent itself, an unwanted effect.

In the following constellations, the profile was NOT active during the build:

2.1 Activation via System Property defined in the parent. Profile not mentioned in the child. Maven Property set within the child.

2.2 No explicit activation defined in the parent. Activation via System Property defined in the child. Maven Property set within the child.

It appears that the property resolving mechanism for the activation of plugins has already been changed for Maven 3. There, the normal Maven Properties are evaluated, not only the System Properties. I do not know if it has been considered to include this nice behavior also in Maven 2, I personally would like to see that.

> If you can supply a failing test case and detailed instructions to reproduce this error, we can reopen it.
What is this for a nonsens? tony ns provided a test case and instructions how to reproduce is clear. What is unclear is how you fixed it? You have modified the original and then you can't reproduce? What does that prove? I can only tell that I am still facing the very same problem with M3.

Can we get someone to look at this? This is definitely still an issue. I have a project that has a top level parent which all other components (100's) eventually inherit from and it is not acceptable to have to copy paste this profile to every component.

The profile defined in the parent is not being inherited from any child to be activated. If you use the exact test case to reproduce this, you can in fact easily reproduce it.

Edit: after playing around with it some more, it seems to be fine and it was my user error

We have the same problem. This ticket really need to be reopened. I will clone it because I fear nobody look at the Closed ticket comments. (See MNG-5127)

John Casey,

> If you can supply a failing test case and detailed instructions to reproduce this error, we can reopen it.

I know it's been 3 years, but can you please take a look at my comment and sample project on MNG-5127 ?