Community
Participate
Working Groups
build I20021127 Using the spy tools, it shows that Update Core is activated in: Activating plugin: org.eclipse.update.core Plugin activation stack: org.eclipse.update.core Class loading stack: Stack trace: jjava.lang.Throwable at org.eclipse.core.internal.runtime.PluginStats.traceActivate (PluginStats.java:89) at org.eclipse.core.internal.runtime.PluginStats.startActivation (PluginStats.java:71) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation (PluginDescriptor.java:187) at org.eclipse.core.internal.plugins.PluginClassLoader.activatePlugin (PluginClassLoader.java:59) at org.eclipse.core.internal.plugins.PluginClassLoader.internalFindClassParentsSel f(PluginClassLoader.java:137) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.findClassParentsSelf (DelegatingURLClassLoader.java:490) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass (DelegatingURLClassLoader.java:880) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.access$0 (DelegatingURLClassLoader.java:874) at org.eclipse.core.internal.boot.DelegatingURLClassLoader$DelegateLoader.loadClas s(DelegatingURLClassLoader.java:89) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.findClassPrerequisites (DelegatingURLClassLoader.java:554) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass (DelegatingURLClassLoader.java:888) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass (DelegatingURLClassLoader.java:860) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at org.eclipse.ui.internal.Workbench.collectFeatures (Workbench.java:1078) at org.eclipse.ui.internal.Workbench.readFeaturesInfo (Workbench.java:1105) at org.eclipse.ui.internal.Workbench.getNewFeaturesInfo (Workbench.java:517) at org.eclipse.ui.internal.Workbench.collectNewFeaturesWithPerspectives (Workbench.java:1267) at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1221) at org.eclipse.ui.internal.Workbench.access$7(Workbench.java:1200) at org.eclipse.ui.internal.Workbench$8.run(Workbench.java:838) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:843) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.ui.internal.Workbench.openPreviousWorkbenchState (Workbench.java:790) at org.eclipse.ui.internal.Workbench.init(Workbench.java:603) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1346) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:841) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) This is to determine which new features have been added, in order to show a welcome page describing the new features. This support was requested by WSADIE and was put into 2.0.2. However, apparently update core accounts for 500K of footprint, according to Jeff (I wasn't running using Sidecar to get these figures). We could add a preference for recognizing new features, leave it off by default, and allow products to customize this preference to turn it on. This won't actually help much though, since this would only work for the case where WSADIE was the initial install, which is not the case for which this support was requested (adding WSADIE after the fact to WSAD and seeing the new features). We should investigate lighter-weight ways of recognizing that there are new features. Perhaps Update could create a file in a well-defined location, indicating that there are new features and their ids. We would just read the file (and erase it), without activating Update Core.
Update should look at why Update Core is so expensive.
When new features are laid down, core boot recognizes this and passes a command line arg, "-newUpdates", to the main app (the workbench) indicating that there are new features. We check for this in Workbench.checkUpdates(), prompting whether to install them. When they are installed, we are restarted (without any command line arg). The new features then appear this second time around. To avoid activating Update Core, we should set a flag when we see the - newUpdates arg. On subsequent restarts, we should only check for new features if this flag is set (and clear the flag when done). Can use a persistent property on the workspace root for the flag. The flag should be removed when cleared (rather than assigning false).
Seems like update should be able to tell the rest of the platform when a new feature has neen *installed*. What happens now is that it tells us that a new feature has been *laid down*. Should see if the update guys can generate the fuller lifecycle. See bug 27412
Even if we end up managing the flag ourselves, we should not use persistent properties on the workspace, since the Workbench and Update should be able to work independently of Core Resources.
Added the fix based on getFeaturesChangeStamp(). The update plugin will be activated the first time the workbench is started because we need to build a collection with all features and open the welcome pages.
*** Bug 27357 has been marked as a duplicate of this bug. ***
Verified that update core is no longer activated on startup. However, there is strange behavior when I start with a fresh workspace and try to look at the plug-ins contributed by a feature. Opened bug 28543.
