Bug 20910

Summary: Updating multiply-installed features
Product: [Eclipse Project] Platform Reporter: Vlad Klicnik <klicnik>
Component: Update (deprecated - use Eclipse>Equinox>p2)Assignee: Dejan Glozic <dejan>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P1 CC: greg_adams, manahan, patmc
Version: 2.0   
Target Milestone: 2.0.2   
Hardware: PC   
OS: Windows 2000   
Whiteboard:
Bug Depends on:    
Bug Blocks: 20867    

Description Vlad Klicnik CLA 2002-06-24 14:33:39 EDT 
The update support currently allows a feature to be installed (natively or 
using update) on multiple local "sites". When the user selects an update for 
this feature, update manager picks one of these and updates it. There are two 
problems associated with this:

(1) we do not offer the user the choice of which to update (currently we pick 
one of the sites, likely the first one we find containing the feature)
(2) we should give the user the choice to actually apply the update to multiple 
(all) installed feature dups.

Also see bug 20867 for a scenario (with attached test cases) where this was 
causing a problem.
Comment 1 Greg Adams CLA 2002-07-08 12:10:58 EDT 
We also require this addressed. Upgrading severity.
Comment 2 Greg Adams CLA 2002-07-08 12:12:16 EDT 
We also require this addressed. Upgrading severity.

The same feature can be installed by multiple products. When these products 
merge together the features show up multiple times. When installing updates  to 
such a dynamic merge eclipse randomly picks one site to update. In this case if 
that site were removed the update would be lost.
Comment 3 Dejan Glozic CLA 2002-09-24 19:45:08 EDT 
The supplied test case is overly simplistic. A more realistic situation is when 
distinct root features in multiple extension drag in duplicate features as part 
of their hieararchies (built by including other features). As products grow 
larger and new extensions are added, the possibility for these types of 
collisions are growing.

A typical example is: a product A has a feature hierarchy, and deep in the
hierarchy is a feature Foo 2.0.0. Later on, an extension B is installed
and Foo 2.0.0 is also included in B's hierarchy. Although the conflict
exists right away (Foo 2.0.0 is enabled in two local sites, which results
in duplicate plug-ins being passed to the Eclipse runtime), there are no
serious consequences beyond warnings in the Eclipse log file. 

If search for updates returns new version of product A (which includes
feature Foo 2.1.0), product B will still keep pointing at Foo 2.0.0
but because both Foo 2.1.0 and Foo 2.0.0 are enabled (in two separate
local sites), Foo 2.1.0 plug-ins will win at runtime and extension B
will be updated against its will (because it will be forced to
use Foo 2.1.0 plug-ins).

Update cannot address this problem actively at the moment because it
cannot control feature lineups of individual products and extensions. 
What we can do (at least for 2.0.2) is do a before/after analysis during
the update search and warn the user about these problems. The warning
will be presented to the user in the update wizard, allowing him to
back out of update due to the possible duplicate conflict. Although
there is a possibility for two root features (A and B in this case)
to keep each other hostage (by providing incompatible updates),
eventually a combination of A and B versions will arrive where
the conflict will not exist if both A and B are updated at the same time
(in our example, that would mean that both updates include Foo 2.1.0).
That would reduct conflict to the original one (duplication of
plug-ins).
Comment 4 Dejan Glozic CLA 2002-10-04 17:38:31 EDT 
Implemented - ready to test.
Comment 5 Dejan Glozic CLA 2002-10-17 16:48:01 EDT 
Tested.