Community
Participate
Working Groups
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.
We also require this addressed. Upgrading severity.
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.
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).
Implemented - ready to test.
Tested.
