Maven
  1. Maven
  2. MNG-4516

Contradiction between the documentation and Maven's behavior related to profile-activation with multiple criteria

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Incomplete
    • Affects Version/s: 2.2.1
    • Fix Version/s: None
    • Component/s: Profiles
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      4

      Description

      The chapter 5.3.1 of the Maven Complete Reference (edition 0.2.1, Novemeber 2009) speaks unambiguously about considering a logical "AND" between more activation-conditions of a profile (cit.: "A profile is activated when all activation criteria has been satisfied. For example, a profile could list an Operating System family of Windows, and a JDK version of 1.4, this profile will only be activated when the build is executed on a Windows machine running Java 1.4.").
      Suprisingly, Maven's real behavior suggests, that the logical "OR" operator is used. The attached demo project contains a profile with two activation-criteria: a property and the existence of a file. As the output shows (attachement output.txt), the fulfillment of a single criterion is enough for activating the profile. Also the corresponding implementation in the Maven core expresses the intention to use an "OR" logic (maven-project/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java r813685 (branch 2.2.x), line 268):

      for ( Iterator activatorIterator = activators.iterator(); activatorIterator.hasNext(); )
      {
      ProfileActivator activator = (ProfileActivator) activatorIterator.next();

      if ( activator.canDetermineActivation( profile ) )
      {
      if ( activator.isActive( profile ) )

      { return true; }

      }
      }

      return false;

      As I'm considering the documentation's variant more reasonable, I'm reporting this as a bug instead of a documentation-issue.

      1. debug_output.txt
        13 kB
        Barnabas Bodnar
      2. output.txt
        3 kB
        Barnabas Bodnar
      3. pom.xml
        2 kB
        Barnabas Bodnar

        Issue Links

          Activity

          Hide
          Dennis Lundberg added a comment -

          If you read this:
          http://maven.apache.org/guides/introduction/introduction-to-profiles.html

          you will see:

          "As of Maven 2.0.9, the tags <exists> and <missing> could be interpolated. Supported variables are system properties like $

          {user.home}

          and enviroment variables like $

          {env.HOME}

          . Please note that properties defined in the POM itself are not available for interpolation here."

          Show
          Dennis Lundberg added a comment - If you read this: http://maven.apache.org/guides/introduction/introduction-to-profiles.html you will see: "As of Maven 2.0.9, the tags <exists> and <missing> could be interpolated. Supported variables are system properties like $ {user.home} and enviroment variables like $ {env.HOME} . Please note that properties defined in the POM itself are not available for interpolation here."
          Hide
          Barnabas Bodnar added a comment - - edited

          In my example-project I didn't use variables (except in the project-name and the local ones in the Ant-part). Besides, what should of effect have the interpolation onto the logical relation between the activation criteria?

          Show
          Barnabas Bodnar added a comment - - edited In my example-project I didn't use variables (except in the project-name and the local ones in the Ant-part). Besides, what should of effect have the interpolation onto the logical relation between the activation criteria?
          Hide
          Barnabas Bodnar added a comment -

          I have provided another example (example2.zip), analogue to that mentioned in the chapter 5.3.1 of the Maven Complete Reference. The profile-activation is conditioned by two critera: the operating-system family Windows and JDK version 1.5:

                <activation>
                    <os>
                        <family>windows</family>
                    </os>
                    <jdk>1.5</jdk>
                </activation>
          

          By the documentation, it is expected that the profile will only be activated when the build is executed on a Windows machine running Java 1.5.
          However, executing the build under Windows with JDK 1.6 already leads to the activation of the profile (see example2.zip#output_windows_jdk16.txt), similarly to executing the build under Linux with JDK 1.5 (see example2.zip#output_linux_jdk15.txt). Consequently, one single criterion was enough for activating the profile, in contrast to the behavior described in the documentation ("A profile is activated when all activation criteria has been satisfied.").

          Is the actual behavior the intended one and the documentation erroneous, or inversely?

          Show
          Barnabas Bodnar added a comment - I have provided another example (example2.zip), analogue to that mentioned in the chapter 5.3.1 of the Maven Complete Reference. The profile-activation is conditioned by two critera: the operating-system family Windows and JDK version 1.5: <activation> <os> <family>windows</family> </os> <jdk>1.5</jdk> </activation> By the documentation, it is expected that the profile will only be activated when the build is executed on a Windows machine running Java 1.5 . However, executing the build under Windows with JDK 1.6 already leads to the activation of the profile (see example2.zip#output_windows_jdk16.txt), similarly to executing the build under Linux with JDK 1.5 (see example2.zip#output_linux_jdk15.txt). Consequently, one single criterion was enough for activating the profile, in contrast to the behavior described in the documentation ("A profile is activated when all activation criteria has been satisfied."). Is the actual behavior the intended one and the documentation erroneous, or inversely?
          Hide
          Barnabas Bodnar added a comment - - edited

          Apparently it was consciously decided for an "OR"-logic in the version 2.0.x (MNG-3106), although the documentation of that version too spoke about an "AND"-logic. Which were the reasons for it?

          Show
          Barnabas Bodnar added a comment - - edited Apparently it was consciously decided for an "OR"-logic in the version 2.0.x ( MNG-3106 ), although the documentation of that version too spoke about an "AND"-logic. Which were the reasons for it?
          Hide
          Eric Pabst added a comment -
          Show
          Eric Pabst added a comment - I have a fix for this here: https://github.com/epabst/maven-3/tree/MNG-4516
          Hide
          Benjamin Haag added a comment -

          If this Issue was Issues to be reviewed for 3.x, as it says, what were the results?
          Activation via settings.xml is useless without an OR condition.

          And as long as there is an activation used in the settings.xml, it is impossible to choose the correct profile via -P profile on the commandline ...

          Is nobody willing to fix that problem in the official version?

          Show
          Benjamin Haag added a comment - If this Issue was Issues to be reviewed for 3.x, as it says, what were the results? Activation via settings.xml is useless without an OR condition. And as long as there is an activation used in the settings.xml, it is impossible to choose the correct profile via -P profile on the commandline ... Is nobody willing to fix that problem in the official version?
          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
          Hide
          Jason van Zyl added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

            People

            • Assignee:
              Unassigned
              Reporter:
              Barnabas Bodnar
            • Votes:
              12 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: