Maven 2 & 3

Multiple profile activation conditions broken

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.4
  • Fix Version/s: 2.0.10, 2.1.0-M1
  • Component/s: Profiles
  • Labels:
    None
  • Number of attachments :
    0

Description

Having multiple profile activation conditions behaves in an unexpected manner. It doesn't cause a build failure, but the actual algorithm for activating a profile is very different from expected. My expectation was that if you include multiple conditions, they are ANDed together. However what appears to happen is that the conditions overwrite each other.

If an <os> condition is added, it overrides any <property> or <file> conditions regardless of their results.
If a <file> condition is added, it overrides any <property> condition regardless of results

The following table gives a sample of conditions matched, and whether the profile was activated as a result:

Property File OS Result Expected
T T - T T
T F - F F
F T - T F
F F - F F
T - T T T
T - F F F
F - T T F
F - F F F
F F T T F
T T F F F

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-4516 Contradiction between the documentation and Maven's behavior related to profile-activation with multiple criteria

  • Critical - Crashes, loss of data, severe memory leak.
  • Open - The issue is open and ready for the assignee to start work on it.

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-4225 Plugin dependencies are incorrectly included as needed artifacts in IBM JDK 1.5 sr8 and IBM JDK 1.6

  • Blocker - Blocks development and/or testing work, production could not run
  • 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
Andy Bryant added a comment -

If the intention is that multiple conditions are not supported currently for maven activation, it would be much better to fail with an error message rather than current behaviour.

Show
Andy Bryant added a comment - If the intention is that multiple conditions are not supported currently for maven activation, it would be much better to fail with an error message rather than current behaviour.
Hide
Permalink
Bryan Kate added a comment -

This bug is severely limiting, especially since the online documentation indicates an AND operation.

Show
Bryan Kate added a comment - This bug is severely limiting, especially since the online documentation indicates an AND operation.
Hide
Permalink
Andy Bryant added a comment -

Something like the following should do the trick. This modifies the DefaultProfileManager isActive method so that:

  • if no activator matches return false (current behaviour)
  • if any activators match, they ALL must consider the profile to be active

Index: DefaultProfileManager.java
===================================================================
— DefaultProfileManager.java (revision 590008)
+++ DefaultProfileManager.java (working copy)
@@ -254,17 +254,27 @@
{
activators = container.lookupList( ProfileActivator.ROLE );

+ boolean matchedActivator = false;
+ boolean activate = true;
+
for ( Iterator activatorIterator = activators.iterator(); activatorIterator.hasNext(); )
{
ProfileActivator activator = (ProfileActivator) activatorIterator.next();

if ( activator.canDetermineActivation( profile ) )

{ - return activator.isActive( profile ); + matchedActivator = true; + activate &= activator.isActive( profile ); }

}
-

  • return false;
    + if (!matchedActivator)
    + { + return false; + }

    + else
    +

    { + return activate; + }

    }
    catch ( ComponentLookupException e )
    {

Show
Andy Bryant added a comment - Something like the following should do the trick. This modifies the DefaultProfileManager isActive method so that: if no activator matches return false (current behaviour) if any activators match, they ALL must consider the profile to be active Index: DefaultProfileManager.java =================================================================== — DefaultProfileManager.java (revision 590008) +++ DefaultProfileManager.java (working copy) @@ -254,17 +254,27 @@ { activators = container.lookupList( ProfileActivator.ROLE ); + boolean matchedActivator = false; + boolean activate = true; + for ( Iterator activatorIterator = activators.iterator(); activatorIterator.hasNext(); ) { ProfileActivator activator = (ProfileActivator) activatorIterator.next(); if ( activator.canDetermineActivation( profile ) ) { - return activator.isActive( profile ); + matchedActivator = true; + activate &= activator.isActive( profile ); } } - return false; + if (!matchedActivator) + { + return false; + } + else + { + return activate; + } } catch ( ComponentLookupException e ) {
Hide
Permalink
Paul Gier added a comment -

This is now fixed in the 2.0.x branch and trunk.
The new behaviour is that the profile will be activated if any of the activators returns true (i.e. an "or" operation).

Show
Paul Gier added a comment - This is now fixed in the 2.0.x branch and trunk. The new behaviour is that the profile will be activated if any of the activators returns true (i.e. an "or" operation).
Hide
Permalink
John Casey added a comment -

Adding fix-for for both 2.0.10 and 2.1.0-M1, since 2.1.0-M1 will actually be released first and may not incorporate all of the eventual issue fixes released in 2.0.10.

Show
John Casey added a comment - Adding fix-for for both 2.0.10 and 2.1.0-M1, since 2.1.0-M1 will actually be released first and may not incorporate all of the eventual issue fixes released in 2.0.10.
Hide
Permalink
Eric Pabst added a comment -

I have a fix for this here that doesn't modify the pom schema at all and simply switches it from an OR to and AND:
https://github.com/epabst/maven-3/tree/MNG-4516

Show
Eric Pabst added a comment - I have a fix for this here that doesn't modify the pom schema at all and simply switches it from an OR to and AND: https://github.com/epabst/maven-3/tree/MNG-4516

People

  • Assignee:
    Paul Gier
    Reporter:
    Andy Bryant
Vote (7)
Watch (11)

Dates

  • Created:
    Updated:
    Resolved: