Maven
  1. Maven
  2. MNG-3228

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.0.7
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      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.

      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.

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          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.

          Show
          Benjamin Bentmann added a comment - 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.
          Hide
          tony nys added a comment -

          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

          Show
          tony nys added a comment - 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
          Hide
          Jesus Ramos added a comment -

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

          Show
          Jesus Ramos added a comment - 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).
          Hide
          tony nys added a comment -

          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

          Show
          tony nys added a comment - 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
          Hide
          Matthew Lieder added a comment - - edited

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

          Show
          Matthew Lieder added a comment - - edited I can confirm this problem still exists in Maven 2.1.0-M1. Any chance of it being fixed in M2?
          Hide
          Brett Porter added a comment -

          see test attachment in MNG-3897

          Show
          Brett Porter added a comment - see test attachment in MNG-3897
          Hide
          Justin Edelson added a comment -

          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.

          Show
          Justin Edelson added a comment - 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.
          Hide
          John Casey added a comment -

          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.

          Show
          John Casey added a comment - 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.
          Hide
          John Casey added a comment -

          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.

          Show
          John Casey added a comment - 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.
          Hide
          Dieter König added a comment - - edited

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

          {project.build.sourceDirectory}

          /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!

          Show
          Dieter König added a comment - - edited 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>$ {project.build.sourceDirectory} /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!
          Hide
          Sven Ludwig added a comment - - edited

          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.

          Show
          Sven Ludwig added a comment - - edited 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.
          Hide
          wolfgang häfelinger added a comment -

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

          Show
          wolfgang häfelinger added a comment - > 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.
          Hide
          Chris Cooper added a comment - - edited

          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

          Show
          Chris Cooper added a comment - - edited 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
          Hide
          Gilles Scokart added a comment - - edited

          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)

          Show
          Gilles Scokart added a comment - - edited 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 )
          Hide
          Tony Lampada added a comment -

          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 ?

          Show
          Tony Lampada added a comment - 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 ?

            People

            • Assignee:
              John Casey
              Reporter:
              tony nys
            • Votes:
              12 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development