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 Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.0.7
    • Fix Version/s: 2.1.0
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      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
          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:
              18 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: