Bug 31887 - ActivityConstraints makes computes 'after' features wrong
Summary: ActivityConstraints makes computes 'after' features wrong
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Update (deprecated - use Eclipse>Equinox>p2) (show other bugs)
Version: 2.0.2   Edit
Hardware: All All
: P1 blocker (vote)
Target Milestone: 2.1 RC1   Edit
Assignee: Dejan Glozic CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-14 11:43 EST by Dejan Glozic CLA
Modified: 2003-02-14 16:21 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.