Community
Participate
Working Groups
Up to now we included parts of the old Eclipse Update Manager (huh, yes, that was the technology that we used to have before p2) in a deactivated way in the packages (like the Classic/SDK from the Eclipse Platform Team). By setting the 'Classic Update' capabilities, this old part of Eclipse could be used if required. With the move to a 4.x based Eclipse, we should ensure that we remove this left-over from the good old days.
+1 I'd agree with this. Plus I'd assume people could still get it from the repo if they really needed it (as long as Eclipse itself provides it ... assuming, I guess, if it it provided in a feature).
I've been looking into this and traced the feature that contributes the org.eclipse.update.configurator plugin. Unfortunately it is defined in the org.eclipse.rcp feature which makes it nearly impossible to leave it out. Moving to Platform, maybe they've got a good idea.
I intentionally left org.eclipse.update.configurator in place in 4.2. There were too many existing dependencies to the API in this bundle, and since it has always been part of org.eclipse.rcp it seemed too disruptive to remove it. However all the Update UI has been removed so the "Classic Update" capability can still be removed.
Created attachment 215303 [details] patch to remove "classic update" I looked around for where this capability was defined, and found it in org.eclipse.equinox.p2.ui.sdk And, the rub, as far as I know this project has not split streams for 3.8 vs. 4.2, and doubt if they'd want to, for this one thing (and, this late). As far as I know, little as that is, there might be a chance this "extension" could be moved "up" (say, to the Platform sdk level, which is split stream) and then org.eclipse.equinox.p2.ui.sdk would not have it in both stream, but eclipse platform could leave in 3.8 stream, but not include in 4.2 stream? If this is technically possible, my guess is any "classic update" user would be using the whole Platform .... but ... not sure ... there might be some products out there that slice and dice in such a way they'd still need it at the p2 level (in 3.8) to not be disrupted?
adding Ian and Tom for any p2/equinox perspective on "classic update". [As far as I'm personally concerned, it could be removed from 3.8 too ... but ... pretty sure that would be taking it too far, with too little time for community feedback.]
(In reply to comment #5) > adding Ian and Tom for any p2/equinox perspective on "classic update". > > [As far as I'm personally concerned, it could be removed from 3.8 too ... but > ... pretty sure that would be taking it too far, with too little time for > community feedback.] If we are talking about removing the capability as John suggests in comment 3 then +1 from me. I'm not sure if we can remove old update.configurator without advanced notice (and I think we should give that advanced notice now so that we can remove it in a future release).
(In reply to comment #5) > [As far as I'm personally concerned, it could be removed from 3.8 too ... but > ... pretty sure that would be taking it too far, with too little time for > community feedback.] Actually I think we should toss it from 3.8 as well. The beauty of the capabilities design is that someone else can easily drop this information into another plugin to restore the menu items. I spent 30 minutes testing "Classic Update" in 3.8 today. The reality is that the world has moved on, and even though UM still strictly works, it can't understand the dependencies of many features created in the past few years, and there are very few new p2 repositories that still have a site.xml that UM can read. If you fabricate a closed world of entirely old features and update sites then it will work, but this isn't the case for most users. The impression of someone using UM today is that all modern update sites appear to be broken and most features appear to have dependency errors. I will happily do the honours and scrape this vestige of the past off the bottom of Juno's shoes... I will just quickly confirm with the PMC and then do this for RC1.
There wasn't agreement in the PMC to remove this in 3.8 at this stage in the release. I'll move it to Kepler/4.3. This means for Juno we'll be in the same state as we were in 3.7/4.1. If someone discovers and activates this capability they will find it doesn't seem to work. It is buried enough that this isn't a big problem.
Fixed for Kepler M1: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=e066cc8029207bcba85498aae0c80d90030955fe
(In reply to comment #9) > Fixed for Kepler M1: Great! Thanks!
*** Bug 369540 has been marked as a duplicate of this bug. ***
