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:

TakeRemoteChangesThenApplyLocalChangesObjectConflictResolver

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 Eclipse.org 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 http://wiki.eclipse.org/CDO_Source_Installation.

CDO workspace bootstrapping

Remoting with IProgressMonitor

Recently we added optional progress monitoring for remote requests to the Net4j Signalling Platform and I'd like to take this opportunity to explain some of the exciting aspects of Net4j. You can use Net4j to implement synchronous remoting applications as well as asynchronous messaging applications. Depending on the number of Net4j layers you are using you can work buffer-oriented or stream-oriented.

Another multi-purpose technology

The heart of Net4j is a fast and scalable, Java NIO-based buffer switching technology which is completely non-blocking and allows for multiple levels of buffer multiplexing. On top of this buffer-oriented transport layer there is an optional stream-oriented protocol layer which is used to implement application protocols. The framework automatically ensures that multiple such protocols can be multiplexed through a single physical transport connection like a TCP socket and that the transport type can be transparently changed to other mediums like HTTP or JVM.


I think the idea behind Net4j becomes clearer when we look at an example. Let's develop a small protocol to upload files to a remote server with full support of IProgressMonitor over the network. In Net4j this is a single signal (aka communications use-case) of a protocol and we need to provide implementations for both sides of the protocol. We start with the client-side request implementation.


Now the application can create instances of this request and call the send() method on them. The framework in turn calls the requesting() and confirming() methods when the transport layer is able to handle the data. The following example method encapsulates the sending process. Notice how the IProgressMonitor is converted to an OMMonitor.


This simple method can now be used in a workbench action. The transferFile() call is wrapped in a Job to make it run in a background thread and to integrate with the Eclipse Progress view.


The complete source code of this action class is available via CVS. Now we only need a server that is able to receive and handle our request. We start with the server-side request implementation (called an indication).


When the data of an UploadRequest arrives atthe server the Net4j framework creates an instance of our UploadIndication and calls the indicating() and confirming() methods appropriately. Therefor we need to register a signal factory, i.e. a customized protocol. In our case we create the protocol instance on-the-fly inside of the protocol factory.


If the server was expected to run in OSGi/Equinox the only missing thing would be the contribution of this protocol factory to an extension point.


But we want to look at a simple stand-alone version of our upload server.


The complete source code of the server class is available via CVS. To enhance the maintainability of our upload protocol some protocol constants are defined in a common interface. This makes it particularly easier to add new signals.


Now we just need to start the server and watch the console.


And finally we start a runtime Eclipse application with our UploadClientAction deployed. When you click this action a file selection dialog is displayed. The chosen file will be uploaded to the server and stored there in a temp folder. The progress of the upload operation is properly reflected in the Eclipse Progress view and can even be cancelled at any point in time.


This is only one example of the many things you can do with Net4j. Please note that the actual client/server communication in Net4j has some characteristics that differ from other remoting technologies, among them:

1. There are no discrete marshalling/un-marshalling phases. As the client writes data to a stream this data is internally filled into fixed-size buffers and passed to the transport layer as soon as they are full enough. As a consequence the server already starts reading and processing that data while the client is still busy sending more data.
2. Multiple virtual channels can be multiplexed through a single physical transport connection. Each such channel can be associated with its own signal protocol and then be used to multiplex arbitrary numbers of signals into both directions.
   
3. The client and server roles do only apply while establishing a physical transport connection. Once connected both sides can open virtual channels at arbitrary times and send or receive data, possibly through signals.

A larger example of a Net4j application protocol is the one that connects EMF models with a CDO model repository. It is also an asymmetric protocol and consists of a client-side implementation and a server-side implementation.


I hope some of you found this interesting. Maybe I have some more ideas for articles about Net4j in the future...

Eclipse Demo Camp in Berlin

Last week I was at the Eclipse Demo Camp in Berlin, my home town in Germany. This was my second demo camp so I was curious how it would compare to the one I visited early this year in Bern, Switzerland.

Berlin photos of my friend Andreas Mösching

It turned out that they were quite similar. A lot of very interesting presentations coupled with a delicious buffet. Another similarity was the presenters' tendency to completely over-estimate their talking time. I remember that my talk at the EclipseCon 2008 also suffered from this a lot. I think I learned from it and I planned to talk only 15 of my 30 minutes and leave the rest for discussion.

The "Deutsche Dom" (main cathedral in Berlin)

My talk about the CDO Model Repository was the first one in a sequence of eight. Fortunately I managed to show my three architecture slides in 10 minutes, followed by a live demo of another 10 minutes. The rest of the time was dedicated to a lot of questions and answers. Very informative for me and the audience. Thank you!

CDO Architecture

After me Tom Ritter from the Fraunhofer Institut described their ModelBus effort. It reminded me slightly to what I saw in TopcaseD framework and indeed Tom talked about a former cooperation. I wonder if somebody would be interested in evaluating ways to integrate CDO with their ModelBus...

ModelBus

Then Volker Wegert from Siemens had a handicap while showing his SAP R/3 Connector for Eclipse RCP Applications: none of the attendees ever faced SAP back-ends. Nevertheless he managed to make it interesting!

SAP R/3 Connector for Eclipse RCP Applications

Very interesting was Jens von Pilgrim's demo of GEF3D. I was amazed to see what they're able to do with 2D user interfaces! With a handful of code changes they turn an ordinary class diagram editor into a multi-layered 3D editor with connections between the layers and so much more. Amazing. And Jens is a collegue of my new CDO committer Stefan Winkler, so I guess I'll hear from him in the future.

Gef3D

Enrico Schnepel explained us how to use GenGMF to ease the development of GMF editors for large metamodels. I also always thought that the GMF's diagram configuration models are so flexible that they fail to easily support the 95 percent cases. Could be worth a look at GenGMF...

GenGMF

One of the talks was not on the agenda so unfortunately I can not remember the name of the student who showed a demo of his distributed shared model editing framework on top of EMF (or GMF?). In his talk he explained that he investigated CDO and found it inappropriate due to the lack of offline support. What a pity that he did not take the time to contact the CDO team. We are currently investigating ways to provide more disconnected modes of model sharing and it would have been so much nicer to co-operate rather than duplicate efforts! I'd appreciate very much his work in the CDO project and he agreed to consider this. Ed, didn't you mention recently how much you enjoy seeing our team grow and prosper? :P

Shared editing in GMF diagrams

Theofanis Vassiliou-Gioles demonstrated their TTworkbench - an extensible Eclipse based test environment - in a very detailed way. I felt like a trainee...

Buffet between the talks

Stephan Herrmann from the TU Berlin gave the last talk: Plugin reuse and adaptation with Object Teams: Don't settle for a compromise! It looked a bit like an alternative approach to AspectJ and his examples were nearly as amazing as the ones at the ESE talk about Equinox Aspects. I must admit that I'm a bit scared about the security implications about such major changes to published and deployed code, un-anticipated by their providers. But it's clear that many things can be achieved with it that were impossible without.

Object Teams

The demo camp started at 6 p.m. and now it was already far past 10. Only two short breaks so most of us looked a bit tired already and I also decided to go home. For future demo camps I would really limit the presentation time to 15 minutes per talk and allow for discussion afterwards. It should be clear that a demo camp is not a training where we should learn the last detail of a tool or technology. It should create interest and the wish to dig deeper back at home.

The Fernsehturm in Berlin