Once you’ve configured Eclipse preferences to your heart’s content, you’ll often want to share those preferences across multiple workspaces. Now normally you can go to File > Export > General > Preferences to save your preferences to a properties file which you can then import into the other workspace. This will share settings such as your customised keyboard shortcuts, formatting, repository settings, etc.
But, for some reason, Eclipse doesn’t save perspective/window layouts, such as which views are open and where they are placed in the perspective. So you’ll find yourself spending another half hour configuring the window to the way you like it. After the 3rd workspace you need to create, this becomes frustrating and just wastes time.
Fortunately there are ways to save and restore these settings automatically. The first is to save the perspective into the preferences (currently only works in Eclipse 3, to be fixed in Eclipse 4) and the other is to use Eclipse’s Copy Settings feature when opening the other workspace. I prefer the first option, but I’ll mention the second option and when to use the one over the other.
When working in Eclipse, you’ll often end up with a number of projects in your workspace that constitute an application. You could have a multi-tiered system with a web, server and database project and other miscellaneous ones. Or if you’re an Eclipse RCP developer, you could end up with dozens of plugins each represented by a project.
Although multiple projects give you modularity (which is good), they can make it difficult to manage the workspace (which is bad). Developers have to check out each project individually from different locations in the repository. Sometimes they even have to get projects from multiple repositories. This is a painstakingly long and error-prone task.
But an easier way to manage multiple projects is with Eclipse’s Team Project Sets (TPS). Creating a workspace becomes as easy as importing an XML file and waiting for Eclipse to do its job. Yes, there are other more sophisticated tools out there that do this and more (eg. Maven and Buckminster) but team project sets are a good enough start if you haven’t got anything set up and may be good enough for the longer term as well, depending on how your team works.
Eclipse’s big strength is its plugins – they make it easy to add new features to the IDE. But plugins can make life difficult when you have to reinstall Eclipse (eg. moving up a version) or have multiple installations (eg. for C++, Java and PHP). Because plugins are normally installed in the plugins folder underneath your Eclipse installation, they aren’t shared by other installations
You could always install the plugins again and again for each installation. That would mean for Subclipse (or favourite), your favourite XML editor, UML tool, etc. This is extremely slow and frustrating.
There is a feature that makes life easier though. You can copy plugins to an external folder and create shortcuts to them via link files. Then you can copy these link files to any Eclipse installation.