Usually, one of the first things I see if I launch Eclipse is this dialog:
Actually, that ‘workspace’ thing is one of the most important things in Eclipse to understand. To mess around it can cause a lot of pain. So I have collected some ‘lessons learned’ around workspaces.
The Workspace .metadata folder
The workspace is where Eclipse stores that .metadata folder:
In this folder, Eclipse stores all the workspace settings or preferences I configure e.g. using the menu Window > Preferences.
:idea: Sometimes that .metadata folder is named ‘Framework’ too. E.g. if I’m are asked by Eclipse to store some settings in the ‘frame work’ then this means it will be stored in the .metadata.
Eclipse uses this folder as well to store internal files and data structures. And many plugins store their settings in here to. Consider the content of this folder as a ‘black box’: so do not change it, do not touch it unless you *really* know what you are doing!
:!: Do not copy or move that folder. If you want to copy/share your workspace settings, then do *not* copy the .metadata folder, as typically you cannot use this folder on another machine or for another user. If you want to transfer/copy your settings, then see this post.
Workspace and Eclipse Versions
As Eclipse stores information in the .metadata workspace structure, the data/format might be different from version of Eclipse to another (e.g. from one version of CodeWarrior to another). While using the same workspace with different versions of Eclipse might :!: work, it is *not* recommended. The Eclipse community tries hard to keep things compatible, but using a different workspace for different Eclipse versions is what I recommend.
:idea: I started to name my workspace(s) like ‘wsp_lecture_10.2’ or ‘wsp_lecture_10.3’ to show that I’m using it for a specific version of CodeWarrior.
Workspace and Projects
This leads to the question:
“Do I have to duplicate then my projects if using with different versions of Eclipse in parallel?”
The answer is ‘no’. Because the workspace folder does *not* have to have the projects in it (as folders). They can, but it is not needed. For example I have different workspaces (“wsp_10.3”, “wsp_10.2”), but my projects are in the “Projects” folder somewhere else on my disk. What I do is to import the projects into each workspace, keep the projects in their original folder location. The menu File > Import > General > Existing Projects into Workspace can be used, with ‘Copy projects into Workspace’ *unchecked*:
:idea: An easy trick is to drag&drop the project folders into Eclipse: that’s much faster and simpler in my view than using above dialog.
Tip: Showing the current workspace in the title bar
Using multiple workspaces can be confusing at some time. See this post how you can show the workspace in the application title:
Processor Expert has a special setting in the workspace pointing to its ‘data base’. That data base is inside the installation folder, in the MCU\ProcessorExpert folder. If a launch Eclipse and use a workspace from a different installation, I get a warning dialog:
:!: That path setting of Processor Expert (pointing to the installation folder) is in my view the biggest argument to *not* share a workspace between different versions of Eclipse.
Pressing the ‘Open Preferences’ opens the settings, and with ‘Restore Defaults’ it will (after a restart of Eclipse) use the new installation path:
:!: That warning might not come up if using multiple installations of CodeWarrior. It seems that as long there is a valid path to a Processor Expert data base, the warning might not show up, and it will use that data base. That can lead to weird behaviour, so better check that the path in the workspace setting is pointing to the right folder.
Workspace Dialog on Startup
Remember that dialog at the beginning of this post? If I want to change if (and what) is shown at Eclipse startup, then this is configured with the menu Window > Preferences > General > Startup and Shutdown:
:idea: In this dialog I can remove items from the list (e.g. if a workspace folder does not exist any more).
As Eclipse stores a lot of information in the workspace .metadata, that folder can grow to a substantial size (several hundreds of MBytes, depending on usage and configuration). One reason is because Eclipse stores local history and undo information into that .metadata folder.
:idea: Just have a look at .metadata\.plugins\org.eclipse.core.resources\.history
So from time to time (especially if I think that Eclipse is slowing down), I export my workspace settings (File > Export > General > Preferences, see Copy my workspace settings) and re-import it again into the new workspace.
- Eclipse stores all its workspace settings and files in the .metadata folder.
- Never touch/copy/change/move the .metadata folder.
- Use different workspaces for each Eclipse version.
- Store the projects outside of the workspace if you want to share them across different Eclipse versions.
Happy Workspacing :-)