Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 311590

Summary:	Remove all Update Manager API
Product:	[Eclipse Project] Platform	Reporter:	John Arthorne <john.arthorne>
Component:	Update (deprecated - use Eclipse>Equinox>p2)	Assignee:	John Arthorne <john.arthorne>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	akurtakov, bbelyavsky, daniel_megert, dj.houghton, irbull, krzysztof.daniel, Lars.Vogel, martin.skorsky, octavioc, rowlands, samuel.wicky, tfletche, tjwatson
Version:	3.6	Keywords:	api
Target Milestone:	4.2
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	367924
Bug Blocks:	366701, 518351

Description John Arthorne

2010-05-04 13:32:47 EDT

The functionality provided by the <code>org.eclipse.update</code> component (known as <i>Update Manager</i>), was replaced in the Eclipse 3.4 (June 2008) release by Equinox p2. As use of more advanced p2 capabilities becomes more widespread, Update Manager APIs will have increasingly incorrect behavior as they fail to understand the different software layouts and richer metadata provided by p2. For example:

- p2 supports *not* installing feature JARs, but Update Manager relies on the presence of features to behave correctly
- p2 supports bundle pooling where bundles and features are stored in a different location. Update Manager is not able to find these new locations and will not behave correctly when bundle pools are used
- p2 supports arbitrary LDAP filters on dependencies, to allow certain dependencies to be ignore when a given property is defined on the profile. Update Manager cannot understand such filters and will ignore such dependencies entirely.
- p2 supports negation of dependencies (I require X to *not* be present), which Update Manager's resolver is not able to understand.

As long as software does not exploit such capabilities, Update Manager APIs will behave correctly, but as these capabilities are exploited, clients relying on Update Manager will begin to fail. For this reason the deprecated Update Manager API should be removed from the platform.

Note that since Update Manager is cleanly separated into its own bundles, it will still be possible for a client to install them separately into their own product if desired, even after they are removed from the Eclipse platform.

Also note that Equinox p2 will continue to provide full compatibility for features and update sites created for Update Manager. I.e., such artifacts will be understood and handled correctly by the Eclipse platform after Update Manager is removed.

The bundles to be removed are:

- org.eclipse.update.configurator
- org.eclipse.update.core
- org.eclipse.update.scheduler
- org.eclipse.update.ui

Related links:

http://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy

Comment 1 Thomas Watson

2011-03-17 13:49:10 EDT

For clarity, are we thinking this would be done in Indigo (3.7) or after?

Comment 2 John Arthorne

2011-03-17 20:20:32 EDT

(In reply to comment #1)
> For clarity, are we thinking this would be done in Indigo (3.7) or after?

They were deprecated in 3.6, so they could be released any time *after* 3.8.

http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/porting/removals.html

Comment 3 Jon Rowlands

2011-05-18 13:29:12 EDT

Can you add a comment outlining how to migrate clients of these APIs to P2?
e.g. list concepts and API names from update manager vs the corresponding in P2

Comment 4 Octavio Cordova

2011-09-01 15:14:04 EDT

is there any update regarding comment 3?

Comment 5 John Arthorne

2012-01-09 17:04:27 EST

(In reply to comment #3)
> Can you add a comment outlining how to migrate clients of these APIs to P2?
> e.g. list concepts and API names from update manager vs the corresponding in P2

I'm not very familiar with the old update API, but there is an introduction to the p2 API here:

http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/guide/p2_api_overview.htm

Conceptually they are very different systems. I suspect the p2 "operation" API is the closest level of abstraction to the provisional API that was provided in the update manager.

Comment 6 John Arthorne

2012-09-27 14:29:29 EDT

These APIs were removed in the Juno (4.2) release.

Comment 7 Lars Vogel

2013-11-13 12:23:35 EST

> 
> The bundles to be removed are:
> 
>  - org.eclipse.update.configurator
>  - org.eclipse.update.core
>  - org.eclipse.update.scheduler
>  - org.eclipse.update.ui
> 
> Related links:
> 
> http://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
> http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy


I think the following plug-in has not yet been removed from the master branch. 

org.eclipse.update.configurator
org.eclipse.update.core

Suggested fix:

https://git.eclipse.org/r/18347

Comment 8 John Arthorne

2013-11-13 14:14:54 EST

I was a bit short on details in the bug. org.eclipse.update.core is left in master because it is still used in some of our tests. org.eclipse.update.configurator is still shipped in the platform because it it used quite extensively in PDE and I felt it was not worth the effort to migrate. It is only 3 API classes so a tiny fraction of old update. I am going to mark this fixed again based on the vast majority being removed in Juno. If you or someone else is offering to migrate PDE and all our tests off these remaining pieces we can revisit that in a separate bug, but I don't see a lot of value there relative to the effort needed.

Comment 9 Alexander Kurtakov

2013-11-13 14:29:43 EST

(In reply to John Arthorne from comment #8)
> I was a bit short on details in the bug. org.eclipse.update.core is left in
> master because it is still used in some of our tests.
> org.eclipse.update.configurator is still shipped in the platform because it
> it used quite extensively in PDE and I felt it was not worth the effort to
> migrate. It is only 3 API classes so a tiny fraction of old update. I am
> going to mark this fixed again based on the vast majority being removed in
> Juno. If you or someone else is offering to migrate PDE and all our tests
> off these remaining pieces we can revisit that in a separate bug, but I
> don't see a lot of value there relative to the effort needed.

What about bug 367924 ? Is this the PDE migration you speak about ?

Comment 10 John Arthorne

2013-11-13 15:07:48 EST

(In reply to Alexander Kurtakov from comment #9)
> What about bug 367924 ? Is this the PDE migration you speak about ?


That is an example in PDE build, but there are many other references.

Comment 11 Lars Vogel

2017-06-16 05:52:30 EDT

Opened Bug 518351 to finish the removal of the Update Manager API.