Eclipse Workspace Tips

Usually, one of the first things I see if I launch Eclipse is this dialog:

Select a Workspace Dialog

Select a Workspace 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:

Workspace Metadata Folder

Workspace Metadata Folder

In this folder, Eclipse stores all the workspace settings or preferences I configure e.g. using the menu Window > Preferences.

💡 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.

💡 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*:

Importing Projects into Workspace

Importing Projects into Workspace

💡 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:

Workspace shown in title bar

Workspace shown in title bar

Processor Expert

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:

Processor Expert Workspace Warning

Processor Expert Workspace Warning: Current worksapce is configured to use data from another installation of Processor Expert.

❗ 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:

Processor Expert Directory

Processor Expert Directory

❗ 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:

Startup and Workspaces

Startup and Workspaces

💡 In this dialog I can remove items from the list (e.g. if a workspace folder does not exist any more).

Tabula Rasa

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.

💡 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.

Summary

  1. Eclipse stores all its workspace settings and files in the .metadata folder.
  2. Never touch/copy/change/move the .metadata folder.
  3. Use different workspaces for each Eclipse version.
  4. Store the projects outside of the workspace if you want to share them across different Eclipse versions.

Happy Workspacing 🙂

12 thoughts on “Eclipse Workspace Tips

  1. Pingback: Links & reads for 2013 Week 7 | Martin's Weekly Curations

  2. We have to develop a lot under Windows. But our ant build/delivery scripts performing better under linux, our target platform and our test environment is linux. I currently try to put the the eclipse workspace on a samba share on the linux build machine to perform fast ant builds. To have a better performance under Windows I want to keep the .metadata folder locally on windows. Is there a possibility?

    Like

    • Hi,
      well, that might depend how you use it. Usually. the .metadata folder is really not to be shared between machines, and even changing the path (say moving the .metadata from one location to another) is problematic. So you can keep that .metadata locally on windows, but it depends who is using it. If it is just that windows machine, no problem (like if you would share the project in a version control system). If you share that .metadata with different machines, then things might break. In that case, better keep a .metadata for each machine/user.

      Like

      • I want to have one .metadata folder for each machine/user. I don’t need the .metadata folder under linux. I want to have the .metadata folder locally and the projects on the share. I am able to create a workspace locally and import all projects from share but, if I create a project afterwards it is locally too and not on the share. :-/

        Like

      • We have a version control system – svn. But our developers should test there changes, before they commit them – therefore I need the workspace on linux. I don’t want to create several svn branches for each user – just for testing.

        Like

      • You misunderstood. The question is how can I share a workspace between two machines/operating systems for one developer to test the changes, before he commit them? Whatever – I actual see our network is not fast enough to put a workspace on a share, even if I put the .metadata folder locally! But thanks!

        Like

  3. Hi,
    Thanks for sharing the knowledge. One question: When i change my project build settings example compiler, linker, preprocessor settings, will they get stored in “.metadata” folder? I need this info because when a project is shared then if it is built on other machine with or without same Eclipse, then all the build setting should also be carried along with Projects.
    Please let me know

    Like

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.