Community
Participate
Working Groups
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
For clarity, are we thinking this would be done in Indigo (3.7) or after?
(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
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
is there any update regarding comment 3?
(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.
These APIs were removed in the Juno (4.2) release.
> > 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
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.
(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 ?
(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.
Opened Bug 518351 to finish the removal of the Update Manager API.
