Maven 2 & 3

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

Details

  • 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. Text File
    debug_output.txt
    04/Jan/10 11:56 AM
    13 kB
    Barnabas Bodnar
  3. Text File
    output.txt
    04/Jan/10 11:56 AM
    3 kB
    Barnabas Bodnar
  4. XML File
    pom.xml
    04/Jan/10 11:56 AM
    2 kB
    Barnabas Bodnar

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. MNG-1753 support improved property based profile activation

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-4565 Multiple profile activation conditions does not work

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MNG-3106 Multiple profile activation conditions broken

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

New Feature - A new feature of the product, which has yet to be developed. MNG-1753 support improved property based profile activation

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-3328 Allow multiple profile activation properties.

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Eric Pabst added a comment -

I have a fix for this here:
https://github.com/epabst/maven-3/tree/MNG-4516

Show
Eric Pabst added a comment - I have a fix for this here: https://github.com/epabst/maven-3/tree/MNG-4516
Hide
Permalink
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?

People

  • Assignee:
    Unassigned
    Reporter:
    Barnabas Bodnar
Vote (12)
Watch (14)

Dates

  • Created:
    Updated: