Maven
  1. Maven
  2. MNG-2276

profile activation by property doesn't work with properties defined in settings.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0-beta-1
    • Component/s: POM, Profiles
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      Activating a profile like below doesn't get activated unless the property is set on the CLI. I need to have the property defined in the settings.xml so it's always set.
      <profiles>
      <profile>
      <id>prod</id>
      <activation>
      <property>
      <name>deploy-ct</name>
      </property>
      </activation>

      Further, I noticed that if I set it so that the activation is like:
      <activation>
      <property>
      <name>deploy-ct</name><value>true</value>
      </property>
      </activation>

      The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It is not active if I use "-Ddeploy-ct=false" but the settings descriptor says that the existence of the property is only used if value is not set.

        Issue Links

          Activity

          Hide
          Immo Huneke added a comment -

          There are a number of issues around profile activation. I suspect that the whole area needs a thorough look.

          Show
          Immo Huneke added a comment - There are a number of issues around profile activation. I suspect that the whole area needs a thorough look.
          Hide
          Immo Huneke added a comment -

          Moreover, profile activation based on environment variables doesn't seem to work at all. For example:

          <profile>
          <activation>
          <property>
          <name>env.APPSERVER_ROOT</name>
          </property>
          </activation>
          

          This is ignored, but if the name is java.vendor.url it works fine (because that property is always defined).

          Show
          Immo Huneke added a comment - Moreover, profile activation based on environment variables doesn't seem to work at all. For example: <profile> <activation> <property> <name>env.APPSERVER_ROOT</name> </property> </activation> This is ignored, but if the name is java.vendor.url it works fine (because that property is always defined).
          Hide
          Richard van der Hoff added a comment -

          See MNG-2848 for activating profiles via env vars.

          Activating profiles via properties defined in other profiles (as would be the case for defining a property in settings.xml) is a whole, more complicated, kettle of fish; i guess mvn 2.1 might look at this sort of thing...

          Show
          Richard van der Hoff added a comment - See MNG-2848 for activating profiles via env vars. Activating profiles via properties defined in other profiles (as would be the case for defining a property in settings.xml) is a whole, more complicated, kettle of fish; i guess mvn 2.1 might look at this sort of thing...
          Hide
          Basil James Whitehouse III added a comment -

          Can someone with privileges please add 'Profiles' to the affected components to make it easier for others to find this issue.

          Show
          Basil James Whitehouse III added a comment - Can someone with privileges please add 'Profiles' to the affected components to make it easier for others to find this issue.
          Hide
          Benjamin Bentmann added a comment -

          Demo project. "mvn help:effective-pom -s settings" shows the POM profile is not activated by the property from the settings.xml

          Show
          Benjamin Bentmann added a comment - Demo project. "mvn help:effective-pom -s settings" shows the POM profile is not activated by the property from the settings.xml
          Hide
          Benjamin Bentmann added a comment -

          Supported in r929483.

          In more detail, the process is as follows:

          1. Determine active settings profiles
          2. Collect properties from above profiles
          3. Determine active POM profiles, considering properties collected in step 2

          Hence, profiles within the settings.xml cannot activate each other just like profiles within the POM cannot activate each other.

          Finally, system properties specified on the CLI take precedence over properties from the settings.

          Show
          Benjamin Bentmann added a comment - Supported in r929483 . In more detail, the process is as follows: Determine active settings profiles Collect properties from above profiles Determine active POM profiles, considering properties collected in step 2 Hence, profiles within the settings.xml cannot activate each other just like profiles within the POM cannot activate each other. Finally, system properties specified on the CLI take precedence over properties from the settings.
          Hide
          Mark Michaelis added a comment -

          If my evaluation is correct it also means that profiles from parent POMs cannot activate profiles in child POMs. Is this correct?

          Show
          Mark Michaelis added a comment - If my evaluation is correct it also means that profiles from parent POMs cannot activate profiles in child POMs. Is this correct?

            People

            • Assignee:
              Benjamin Bentmann
              Reporter:
              brianfox brianfox
            • Votes:
              15 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: