|
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 goal is to have all profiles defined in the parent pom, and every child pom inherits this 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 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 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.