Issue Details (XML | Word | Printable)

Key: MNG-3106
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Paul Gier
Reporter: Andy Bryant
Votes: 7
Watchers: 7
Operations

If you were logged in you would be able to see more operations.
Maven 2

Multiple profile activation conditions broken

Created: 13/Jul/07 04:39 AM   Updated: Tuesday 03:46 PM
Component/s: Profiles
Affects Version/s: 2.0.4
Fix Version/s: 2.0.10, 2.1.0-M1

Time Tracking:
Not Specified

Issue Links:
Related
 


 Description  « Hide
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



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Andy Bryant added a comment - 13/Jul/07 04:40 AM
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.

Bryan Kate added a comment - 14/Aug/07 02:41 PM
This bug is severely limiting, especially since the online documentation indicates an AND operation.

Andy Bryant added a comment - 30/Oct/07 05:23 AM
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 )
    {

Paul Gier added a comment - 15/May/08 03:46 PM
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).

John Casey added a comment - 03/Sep/08 04:59 PM
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.