Sunday, December 14, 2008

What is a Workspace?

Stupid question!
It's a space to work in.
Stupid question?

Stupidity, like beauty, is a not context-free

A friend of mine used to complain that we, the guys of the software industry, only have a maximum of four words available to give things a name. That can lead to horrible ambiguities. Acronyms do the rest (see Uncorking CDOs). I agree that meaningful names tend to be longer, which is not always nice, either. Maybe someone can help me to find a shorter name for a strategy class I had to create yesterday:


Well, workspace, I'm wandering from the subject. Often it seems necessary to look at the roles and responsibilities of a technical concept to guess its exact purpose and derive adequat usage rules. So, to re-word my initial question:

How am I supposed to use Eclipse workspaces?

I fear there is no single truth, given the vast number of responsibilities of a workspace:
  1. Manage my projects, associate them with revision control
  2. Manage my JREs/JDKs to compile my Java projects against
  3. Manage my target platform to compile plug-in projects against
  4. Manage my API baselines for plug-in development
  5. Manage my working and display preferences
And certainly some more. Each of the above responsibilities has its own dependencies and implications. For example the target platform and the API baselines are dependent on the projects that currently exist in my workspace. While there can be multiple baselines defined in the global workspace preferences and assigned to particular projects, the target platform is a global setting for the whole workspace. It can not be defined on a per project base. Since the set of projects I'm actively working on varies over time, this requires frequent change of the target platform definition.

The only constant I'm seeing is the set of my personal usage and display preferences. The way I populate my perspectives, the key bindings I'm used to and all the other things that proofed to be useful for me. Exporting and importing these preferences is also not ideal because it doesn't catch all settings (like stored passwords) and leads to redundancy problems.

My favorite decoration of changes

Now I get the feeling that the implications and inherent lifecycles of these responsibilities do not match particularly good together. In fact I'm living with this feeling from the beginning of my Eclipse experiences. The fact that my usage preferences are kind of a singleton at any point in time I'm somewhat reluctant to the idea of maintaining a bunch of separate workspaces. Or am I missing a trick to operate multiple workspaces on an identical set of IDE preferences?

I know that it's only a default behaviour of Eclipse to create and maintain my projects physically inside of my workspace. With some effort I can link in a set of projects that a physically stored in a folder outside of the workspace. The problem is that each set of open projects in the workspace requires a number of particular baselines defined and a number of partular plugin-ins to be present in the global target platform. Not to speak about the needed JREs and possibly other stuff that is required for the workspace projects.

An additional, but related, problem is that the initial check-outs from a revision control system usually require me to know which of the remote folders correspond to proper Eclipse projects and belong to the overall set of projects required for a larger set of functionality (also often called a project!). I know the concept of Team Project Set files (PSF) but they do not address the issue of required preference settings and their management is somewhat redundant, given that I'm already managing the set of projects directly in the workspace. I regularly forget to add new projects to the PSF files, or remove the deleted ones.

Sometimes the right steps are obvious

What I really would like to see is some convenient and consistent tooling that enables me to swap in and out these sets of related projects, together with all their prerequisites! I don't want to clutter my office with a completely new desk each time someone drops a task for me, buying and arranging new pen and ink each time...

Given that Eclipse is on the market for many years now I find it hard to believe that there is no obvious solution to this all-day problem. Well, maybe it's just that I didn't find it.

Geeks, please tell me about your solutions!

From time to time I had the feeling that Buckminster addresses some or all of these issues. Unfortunately I never managed to realize the exact responsibilities and implications of the concepts that Buckminster offers to materialize workspaces. At least I found it hard to map these concepts to my scenarios. I suspect that each flexible solution in this area can not be darn simple and I promise to put another evaluation on my todo list.

By the way, for my Net4j and CDO open source projects at I came up with a mainly Ant-based approach to materialize nearly complete workspaces for the different development streams. Basically it's a two-phase process with a bootstrap phase to check out the setup scripts together with the appropriate PSFs. If you're interested, have a look at my description at

CDO workspace bootstrapping


  1. You should apply the single responsibility principle and break TakeRemoteChangesThenApplyLocalChangesObjectConflictResolver into multiple classes.

    1. TakeRemoteChanges
    2. ApplyLocalChanges
    3. ConflictResolver

    Take RemoteChanges probably uses the other two classes. Right now your class is doing at least two different things. If you have an overly complex name for a class it is probably doing too much.

  2. Some of your workspace woes can be solved by Rational Team Concert ... assuming Eclipse should decide to adopt it. With RTC, you can have multiple workspaces stored in the repository, and have any portion of a workspace repository loaded or unloaded from your "real" workspace. It doesn't solve your problem of target platforms (if any of the PDE developers are reading this, please give some love to target platforms), but it does help manage multiple workspaces.

  3. eike,

    I also spent much time to find the best soultion to manage my workspace.

    the best for me would be ONE workspace, but the problem is the target platform, where I can only use one per workspace.

    some time ago I read from Chris Aniszczyk that there are plans for the future to have target platforms per project. so there's some hope...

    my current decision is to use two workspaces:

    * one workspace for my modeling projects (openArchitectureWare, EMF, UML, my Cartridges and my Generator Projects. I generate code which is written to projects in my second workspace.

    * the 2nd workspace contains all Projects used for runtime aspects: client or server: Riena, UI, Easybeans, ...

    one problem was using Mylyn: I changed Mylyn preferences and use a directory outside the two workspaces, so I can use it from both (but have to be carefully)

    you see, you're not the only one having problems to organize the workspaces, projects etc.

    wish you a nice sunday


  4. David, You're right! We're currently working on a merge result model to enable multiple merge "phases", like auto-merge-for non-conflicting-changes or interactive-merge-for-conflicts, to collaborate on a shared model. This will make it much easier for us to separate the different aspects and implementations of our conflict resolvers. Thank you again for you're valuable hint ;-)

    JC, Jazz is definitely an interesting product. I'm a bit concerned about the open source and licensing strategy. Could these repositories be backed by what we have at, i.e. CVS?

    Ekke, Thanks for the Mylyn hint! I'm also maintaining two workspaces for HEAD and a maintenance branch, and I always was annoyed by the fact that I couldn't manage the read/unread state together. Now I can ;-) Btw, once I started an effort to design a model for these aspects: CVS