Issue Details (XML | Word | Printable)

Key: MNG-3228
Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Major Major
Assignee: John Casey
Reporter: tony nys
Votes: 12
Watchers: 12
Operations

If you were logged in you would be able to see more operations.
Maven 2 & 3

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

Created: 02/Oct/07 06:36 AM   Updated: 25/May/09 06:53 AM   Resolved: 19/Feb/09 02:11 PM
Return to search
Component/s: None
Affects Version/s: 2.0.7
Fix Version/s: 2.1.0

Time Tracking:
Not Specified

Issue Links:
Duplicate
 
Related
 


 Description  « Hide

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.



Benjamin Bentmann added a comment - 09/Nov/07 06:25 PM

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.


tony nys added a comment - 12/Nov/07 12:13 AM

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


Jesus Ramos added a comment - 04/Mar/08 10:04 PM

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


tony nys added a comment - 05/Mar/08 12:38 AM

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


Matthew Lieder added a comment - 11/Dec/08 09:59 AM - edited

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


Brett Porter added a comment - 18/Dec/08 05:34 AM

see test attachment in MNG-3897


Justin Edelson added a comment - 28/Jan/09 07:47 AM

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.


John Casey added a comment - 09/Feb/09 09:35 AM

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.


John Casey added a comment - 19/Feb/09 02:11 PM

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.