There are three broad categories of users when it comes to upgrading, whether we are talking about software applications, operating systems, or hardware. The first category only upgrades when there is a highly compelling reason, such as a new feature that will increase productivity or enjoyment. The second category upgrades on a regular basis because they have found in the past that many multi-generational upgrades are far more difficult than upgrading regularly with each increment. The third category generally prefaces their upgrade path with the words “Ooh! Shiny.” Although I will address only the needs of the first two types of users here in relationship to Eclipse, we should be thankful to that third category of user as they are the ones that bought enough LCD monitors when they were outrageously expensive so that the manufacturers could justify increased capacity and reasonable pricing.
For the purpose of upgrading Eclipse, there are two paths. One is the incremental approach; the other is a major version upgrade. Major version upgrades are essentially a migration, because they require a new installation. There was a time when a major upgrade was required only when the full version number increased (i.e., from 2.x to 3.x). This seems to have moved to one decimal point to the right, as in upgrading from 3.3.x (Europa) to 3.4.x (Ganymede).
Using Software Updates for Incremental Upgrades
Incremental upgrades are great for picking up regular enhancements and bug fixes. If you are the daring type who likes to use the pre-release versions, running these incremental updates on a daily basis is pretty painless. I did this myself for 2.0. Even though the regular update process for pre-releases works well for Eclipse itself, not all plug-in projects are able to keep pace with a pre-release, which leads to some of them ceasing to function after a particular update. This is the main reason that I have not gone the pre-release path since version 2.0.
In my own personal experience, I have found the Eclipse releases so stable that I only run the update when I want to try out a new plug-in that is dependant on a newer incremental release. For those times, and for those who just like to make sure they have the latest and greatest installed, here are the steps for incremental updates to Eclipse.
Eclipse provides two interfaces for updating. Both are accessible from the Help menu:
Figure 1: Two Update Paths from Help Menu
Figure 2: Different Screens, Same Options
For most purposes, the two different views provide the same functionality, leaving the choice to your own personal preference. If you are prompted to select a mirror site, use the Automatically select mirrors option to save you from continuously being prompted during high-traffic periods.
Figure 3: Use Automatically Select Mirrors to Avoid Multiple Prompts
Depending on how often you update and traffic, you may see this screen for quite some time:
Figure 4: Don’t Panic; It Will Eventually Complete
Once the updates are located, you follow the prompts to the installation point. Again, depending on how frequently you run the updates, this may take quite some time. Once complete, you will have the latest incremental release.
Figure 5: The final dialog
Preparing to Migrate to a Major Version Upgrade
When when I first started using Eclipse, I ran regular updates. However, the stability of later versions had put me in the category of only upgrading when I need new features or functionality.
One thing that has changed with Eclipse installations is that several pre-configured downloads are now available from the Eclipse site. Previously, pre-configured packages with related plug-ins were only available from companies such as MyEclipse. Although the Eclipse downloads do not have as broad of a mix of plug-in providers that MyEclipse has, most developers will find the Eclipse downloads quite adequate. Until recently, I ran two versions; one was the Java EE version (available at http://www.eclipse.org/downloads/) and the other was the PDT project version (http://www.eclipse.org/projects/project_summary.php?projectid=tools.pdt) for PHP development.
Recently, I upgraded from Europa to Ganymede. Even though Ganymede had been out for quite some time, the PDT project only recently released version 2.0. The previous version was Europa based. Having a single installation was incentive enough for me to upgrade my PDT version.
Theoretically, it should be as easy to install the PDT extensions into my Ganymede JEE installation. In practice, I find it easier to start with the PDT installation and add the JEE components. This may be because I am more familiar with installing the Java packages separately, or it may be because the Java tools are both the most mature and most popular.
The keys to a smooth migration are organization and/or preparation. It is an and/or proposition because if you aren’t organized, you can make up for in proper preparation and if you are organized preparation is minimal. Either way, the end result will be a list of plug-ins, a set of preferences, and a backup of your previous installation.
As mentioned in “Building the Perfect Portable Eclipse Workbench,” it is very convenient to have plug-ins that are available as downloads because it makes it easier to re-install them. Keeping these downloads organized as you acquire them will make it much easier to find them when you do a major upgrade. However, not all plug-ins are compatible with a newer Eclipse version, which is an argument in favor of the standard URL-based installation. In many cases, you can have a mixture of both types of installations.
If you haven’t kept regular track of plug-ins as you installed them, you can find a list of all of your currently installed plug-ins using the HelpAbout menu.
Figure 6: Find Plug-in Details Under HelpAbout
This approach yields a list of all installed plug-ins, including those that are part of the installation package. Even though those where the provider is eclipse.org are easy to check off the list of your plug-in inventory, some are less obvious, such as those provided by emonic.org; they are also part of the pre-packaged set. A general rule of thumb is if you recognize the plug-in name, note it down for your upgrade process and ignore the rest. The idea behind this decision process is that if you don’t recognize the plug-in name, odds are you don’t use it much (or at all) anyway.
Figure 7: Installed Plug-ins
For the plug-ins that you did a URL-based installation of, you can find the URL by going to the Update dialog and using the Edit function.
Figure 8: Select New Features
Figure 9: Save the Location from the Edit Dialog
For those plug-ins installed manually from downloads, you will want to search the web for their home site. Some of these plug-ins will now have a URL-based installation. In either case, you will want to see whether there is a newer release for the version of Eclipse you are preparing to upgrade to.
Once you have collected your plug-ins to install, you will want to export your preferences from your current Eclipse installation from the FileExport GeneralPreferences menu. I suggest a naming convention for the resulting .epf file that reflects the use of the settings and the date created.
Figure 10: Save Your Preferences By Exporting
The final step in preparing your migration is to back up your workspaces. I suggest you back up to removable media because some plug-ins take advantage of the OS to store preferences that will be lost during the upgrade process.
Steps to a Major Version Upgrade
Now, you are organized and prepared for migrating to the new version. First, unzip the installation to a new path. Next, run your manual plug-in installations. Most of these simply require unzipping the contents of the included plugins folder to the plugins path under your Eclipse installation. Some also have a features folder that requires the same process (unzip the contents to the features path under the Eclipse installation).
If you are taking the same path as I did, using the PDT project as a baseline for both PHP and Java development, your Java plug-ins won’t show up yet. Although the Europa installation of the PDT package included the basic Java development tools, the Ganymede installation has none. You can add them easily with the software installation dialogs (refer to Figures 8 and 9) to add in the Eclipse J2EE options. At the completion of this installation, you will be prompted to re-start Eclipse, and the Java plug-ins will now be available.
Next, start Eclipse and run the URL-based installations through the same dialogs shown earlier in Figures 8 and 9. Some of these may require re-starting Eclipse. Once all of the plug-ins have been installed, import your preferences from the .epf file you exported earlier.
Eclipse allows the use of multiple versions on the same machine, so you will want to decide if is preferable for you to create new workspaces so that you can continue to use your older version, or simply point to the existing workspaces. Both approaches are accomplished through the Import menu; the difference is whether you select the Copy to New Workspace option.
Figure 11: Importing Projects
Next, check your plug-ins. In some cases, your preferences will have been imported from your .epf file. In other cases, the preferences were stored on a workspace level. If they were stored there and are not available after importing your projects, go to the.metadata.plugins path in your backup and you will find the setting stored under the individual plug-in. In some cases, you will simply need to re-configure the plug-in manually, either because the plug-in stored the information in an OS-based path or because the configuration syntax changed between versions.
Conclusion
The Eclipse builds are one of the most stable Open Source projects around. Updates are rarely necessary anymore unless required by a plug-in, and when they are necessary they are simple and painless to run. How easy or difficult a full upgrade will be depends on the plug-ins you use. Hopefully, the steps covered in this article will minimize or even eliminate any difficulties when a full upgrade makes sense for your development needs.
About the Author
Scott Nelson provides optimization services designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profits, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. For information on how he can help with your web applications, please visit http://www.fywservices.com/. He also blogs all of the humorous emails forwarded to him at Frequently Unasked Questions.
