Community
Participate
Working Groups
RCP changes had a side effect on the update manager (I actually like the end result, but it is a regression): - launch M5 and then shut it down. - unzip a new feature into the features/ folder - restart eclipse - the old behavior: after the reconciler runs and detects the new feature, a dialog prompts the user to accept or reject the newly discovered feature - the M5 behavior: nothing happens. You can still go to the Help>SoftwareUpdates>Manage Configuration, turn on disabled features filter and enable the unzipped feature. It looks like IDEWorkbenchAdviser.checkUpdates() invokes this dialog (indirectly) by first checking if "-newUpdates" is on the command line. Somehow, this string is not present.
(Similar to bug47469.)
This is a note from Christophe Elek who wrote the original code: <note> I have to check the code in details but I believe the path is the following PlatformConfiguration detect change on the file system (a new feature is a change, a new plug-in without a feature is not a change) PlatformConfiguration calls the UpdateManager core and asks for reconciliation Update Manager reconciles (the best it can :) and saves data in a file (the name escapes me) UM shuts down Startup catches the shutdown and restarts PlatformConfiguration (I believe I will need to check) finds the file and calls -newUpdate I will have to check the name of the file and the behavior of the last sentence checking... Ok, it is in PlatformConfiguration private static final String CHANGES_MARKER = ".newupdates"; //$NON-NLS-1$ private static String[] checkForNewUpdates(IPlatformConfiguration cfg, String [] args) { try { URL markerURL = new URL(cfg.getConfigurationLocation(), CHANGES_MARKER); File marker = new File(markerURL.getFile()); if (!marker.exists()) return args; // indicate -newUpdates marker.delete(); String[] newArgs = new String[args.length + 1]; newArgs[0] = CMD_NEW_UPDATES; System.arraycopy(args, 0, newArgs, 1, args.length); return newArgs; } catch (MalformedURLException e) { return args; } } Update Manager Reconciler does private void markChanges(IPlatformConfiguration cfg) { // indicate we have changes in restart scenario ... converted to -newUpdates on restart FileOutputStream fos = null; try { URL markerLocation = new URL(cfg.getConfigurationLocation(), CHANGES_MARKER); fos = new FileOutputStream(new File(markerLocation.getFile())); fos.write(0); fos.close(); } catch (IOException e) { if (fos != null) try { fos.close(); } catch (IOException e2) { } } } So if the file is not generated, either PlatformConfiguration didn't pick up changes (you can trace the execution) or I didn't save any marker If the file is created, maybe cfg.getConfigurationLocation() is not resolved properly </note>
It looks like update works as Chris describes, and the problem is in the InternalBootLoader class, likely caused by RCP changes. I added my comments <db></db> in the code that seems to cause the problem: /** * @see BootLoader */ public static String[] startup(URL pluginPathLocation/*R1.0 compatibility*/, String location, String[] args, Runnable handler) throws Exception { assertNotRunning(); starting = true; commandLine = args; String[] applicationArgs = initialize(pluginPathLocation, location, args); <db> at this point, applicationArgs[0] is "-newUpdates", which is correctly computed. </db> Class platform = loader.loadClass(PLATFORM_ENTRYPOINT); Method method = platform.getDeclaredMethod("loaderStartup", new Class [] { URL[].class, String.class, Properties.class, String[].class, Runnable.class }); //$NON-NLS-1$ try { URL[] pluginPath = getCurrentPlatformConfiguration ().getPluginPath(); <db> when we call the loaderStartup, we don't pass applicationArgs (that contain -newUpdates, but we pass args, and args does not contain -newUpdates) </db> method.invoke(platform, new Object[] { pluginPath, baseLocation, options, args, handler }); } catch (InvocationTargetException e) { if (e.getTargetException() instanceof Error) throw (Error) e.getTargetException(); else throw e; } // only record the platform as running if everything went swimmingly running = true; starting = false; return applicationArgs; To see the scenario, run eclipse, shutdown. Then drop a new feature in eclipse/features and then restart. What happens is: during the first pass, update detects the new feature, creates eclipse/.config/.newupdates and restarts the platform. Upon restart, .newupdates is detected, and -newUpdates is added on the list of arguments. As described above, this arguments are not actually used anywhere. I will append a feature that you can use for testing.
Created attachment 6983 [details] feature to drop in the install to test the problem
*** Bug 47842 has been marked as a duplicate of this bug. ***
We have another startup related bug (infinite startup loop after installing new features), that could be related to this bug, but can't tell for sure: bug 47861. What is the esitmate time for fixing this bug ?
Created attachment 7038 [details] Patching ConfigurationActivator
decreasing priority as a patch has been submitted and is being released
The patch works only for bug 47842 but not for the problem described initially. See my original comments about where the problem seems to be located.
It was the only case I was trying to fix. The other problems seems to be related to the PlatformConfiguration object willing to run the reconciler.
This is fixed in N20031208. Closing.
Original problem still not solved: RCP changes had a side effect on the update manager (I actually like the end result, but it is a regression): - launch M5 and then shut it down. - unzip a new feature into the features/ folder - restart eclipse - the old behavior: after the reconciler runs and detects the new feature, a dialog prompts the user to accept or reject the newly discovered feature - the M5 behavior: nothing happens. You can still go to the Help>SoftwareUpdates>Manage Configuration, turn on disabled features filter and enable the unzipped feature. It looks like IDEWorkbenchAdviser.checkUpdates() invokes this dialog (indirectly) by first checking if "-newUpdates" is on the command line. Somehow, this string is not present." As far as I can tell, this is an RCP defect.
As pointed earlier the problem comes both from the fact that PlatformConfiguration is invoked later than before and the way parameters are passed around in the new runtime. In eclipse 2.1, PlatformConfiguration.startup was called really early by the InternalBootLoader and was modifying the content of the command line (for example adding the -newUpdate argument (see last method class in startup)). Therefore every caller higher on the chain were able to see this new parameter. Now the PlatformConfiguration is called as a regular bundle (update.configurator) and by consequence once the system is up and running. At that time, it is impossible to change the command line args. Basically PlatformConfiguration needs to find another way to indicate the - newUpdate. One solution could be a system property.
In the latest integration build (0223) any new feature or plugin is automatically added to the configuration. The direction for installing updates is to have eclipse ship with a predefined configuration and install new features using the update manager UI or standalone commands. Unzipping features/plugins will still work, but is not what we encourage. There is some effort into getting better tooling for developing and deploying features, and to improve the installation process.
Fixed, as per comment #14. Use the latest 0303 integration build, for latest fixes.
