Bug 31887

Summary: ActivityConstraints makes computes 'after' features wrong
Product: [Eclipse Project] Platform Reporter: Dejan Glozic <dejan>
Component: Update (deprecated - use Eclipse>Equinox>p2)Assignee: Dejan Glozic <dejan>
Status: RESOLVED FIXED QA Contact:
Severity: blocker    
Priority: P1 CC: celek, stephen.francisco
Version: 2.0.2   
Target Milestone: 2.1 RC1   
Hardware: All   
OS: All   
Whiteboard:

Description Dejan Glozic CLA 2003-02-14 11:43:39 EST
Every update operation is checked in 'ActivityConstraints' class where 'before' 
and 'after' states are computed to verify that the proposed operation will 
result in a valid state.

In case of an install or update, it works as follows:

1) It computes the 'before' list. It contains all the local features currently 
installed in the product.
2) It computes 'add' list. It contains all the remote features that will be 
added.
3) It computes 'remove' list. It contains all the local features that will be 
removed from the product.

The order is:

after_list = before_list + add_list - remove_list

This algorithm has a flaw in the actual order. 'Before' list contains only 
local features, while the 'add' lists contains only the remote features. After 
the first addition, the resulting list contains a mix of local and remote. When 
the 'remove' list is removed, it removes more features than it should thanks to 
the behaviour of 'IFeature.equals()'. Since this method simply compares id and 
version of a feature, it returns true when a local and a remote feature object 
with the same id and version are compared. We use 'ArrayList'.removeAll' and in 
this process, both the local and the remote feature is removed from the 'after' 
list.

Although 'ActivityConstraints' does not do the actual work - it just makes sure 
the operation will result in a legal state - it prevents the install from 
happening.

The fix is simple - change the order:

after_list = before_list - remove_list + add_list

Since 'before_list' and 'remove_list' are compatible i.e. both contain only the 
local features, the result will be as desired and no excessive removal can 
happen.

This is not a new problem - the same code existed in 2.0 release - we simply 
found about it now. It is a very subtle issue and we stared at the code for a 
while before realizing what happened.
Comment 1 Dejan Glozic CLA 2003-02-14 12:18:54 EST
Fixed in both 2.0.3 and 2.1 streams. Ready for testing.
Comment 2 Dejan Glozic CLA 2003-02-14 16:21:53 EST
Looks good.