Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-2276

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

    Details

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

      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.

      1. mng-2276.zip
        1 kB
        Benjamin Bentmann

        Issue Links

          Activity

          Hide
          immohuneke 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
          immohuneke 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
          immohuneke 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
          immohuneke 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
          richvdh 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
          richvdh 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
          jwhitehouse 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
          jwhitehouse 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
          bentmann 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
          bentmann 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
          bentmann 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
          bentmann 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
          thragor 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
          thragor 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:
              bentmann Benjamin Bentmann
              Reporter:
              brianf Brian Fox
            • Votes:
              15 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development