Community
Participate
Working Groups
Currently, update does not have the capability to update the startup.jar or the eclipse executable. This causes problems when we are creating update jars for a release. For instance, with releases where the startup.jar or eclipse executable needs to be replaced, we cannot provide the update jars because these two files cannot be upgraded by update manager. I spoke to Jeff and he suggested that the startup.jar could be converted to a plugin that could be updated. As for the eclipse executable, there would need to be a mechanism during the update process to -copy the new eclipse.exe to a temporary filename -create a new config.ini with a filename to match the executable -shutdown eclipse -magic bootstrap mechanism to rename the old and new launcher and startup jar -restart eclipse -ability to revert the change if errors occurred This facility would also be useful for updating between milestones or integration builds on the developer update site. Otherwise, the update site stops being useful when either the startup.jar or executable is updated.
I'll just add my "vote" that this capability will be all the more important with the new plugin versioning conventions. I think the "new order of things" will discourage having seperate directories for each seperate releases (since if an "old" plugin never changes, no need to update the file) plus some "prerequites chains" might end up requiring the plugins form different releases, which will be hard (for others) to manage if always in seperate directories. In other words, I'd find it likely that startup.jar, etc., may have to be changed right along with other plugins/features.
This is very annoying. I just started using Eclipse. Two days after installing 3.1.1, 3.1.2 was released. Now I cannot update to 3.1.2 because of this bug. And I don't want to manually mess with the files, because I'm not familiar with the Eclipse directory structure, and I don't want to risk losing/corrupting important files and settings. And since Eclipse doesn't have an installer, it doesn't have an upgrade wizard to import the settings from a previous version on install. Having an installer is a good idea even for applications consisting of a single executable and with no user configurable preferences. Not having one for a application as complex as Eclipse is crazy. So I think this bug deserves a P2 priority.
You can update to 3.1.1 from 3.1.2 See http://www.eclipse.org/eclipse/platform-releng/updatesfor3.1.1.html This bug applies to cases where the launcher and eclipse executables change, for instance, for upgrading from 3.2 to 3.x. Traditionally, the expectation is that product teams who consume eclipse for release in _commercial_ products provide the installer.
In response to comment 2, you *can* export settings and configurations to move them between releases. And if you use the same workspace over and over, chances are you'll persist most of your configurations anyway, without even having to bother. I keep my Eclipse, plugins, and workspaces in three separate places, eg.: e:\eclipse3.2M4, e:\eclipse3.2M5, ... e:\eclipse-plugins, e:\eclipse-emf-plugins, e:\eclipse-uml2-plugins, ... e:\workspace1, e:\workspace2, ... By doing this, you can swap out one component w/o having to reinstall everything, and because your workspace isn't INSIDE your eclispe install, you can just delete it and replace it with a new one without losing any of your project files. To connect external plugin folders into an existing eclipse install, you just have to create a folder called "links" inside the eclipse install folder (next to "plugins" and "features") and into that folder put one or more foo.link, bar.link files, which contain something like: path=e:/eclipse-plugins
Created attachment 35715 [details] shell tool to download and install Eclipse + N additional plugins, like EMF, UML2, etc., and reproduce links folder or create new one as needed For use with Linux - this script will simplify the process of updating from an existing Eclipse install to a new one, including reproducing *.link files, optionally installing other plugins (eg., EMF, UML2), and even creating symlinks so that you can generically run eclipse as ~/eclipse/eclipse instead of ~/eclipse3.2M5/eclipse/eclipse. Doesn't solve the problem of needing an installer, but it's a poor man's solution and/or a place from which a more complex script can be built.
haven't been any comments on this bug for awhile, so don't know whether it's still an open issue... but if it is, sure would be nice if we could guarantee that all 3.2.x -> 3.3 -> N.N platform updates could be done "in place" via the update mgr.
comment #6 See bug 154077 which is a proposed item on the 3.3 plan. http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html
*** This bug has been marked as a duplicate of 154077 ***
