I had a great EclipseCon Europe with great talks, great people and as always delicious food. It was nice meeting and discussing with all of you. I was particularly fascinated how easy it is to start creating something physical on the basis of the Arduino Platform which has been demonstrated by David Cuartielles in his Keynote. When I have some spare time, I'll have to experiment with Arduino! BTW, if you are interested in cool stuff around Arduino, be sure to pay a visit to Makezine.com, a magazine website which shows amazing projects in that area.

Now, as I'm feeling like just coming home from one EclipseCon, the next one is only a short time away; and today is the deadline for talk proposals (So, if you are, like me, waiting for the last second, you should wake up and start writing now!). I actually woke up just yesterday and wrote two proposals which I have been thinking about for several weeks now, but never had to time to write down:

• There and back again -- as quick as a flash will be a talk about the model persistence backend of CDO. I will present the different store implementations and give some insight on how they work. I'll also provide hints on how to tweak performance with the CDO persistence mechanisms.
• Everyday Git will discuss what switching to (E)Git means in terms of the everyday development workflow. Together with Eike Stepper, we will have a look on how CDO handles things with (E)Git not so much on a technical level, but on an organizational/business process level.

I hope you find these talks interesting. If so, please drop by on the session proposal sites and add a comment and/or vote for the talks.

The day has finally come. After months and days of living with the inconveniences of SVN (which, actually, we used to paise and worship after the days of CVS...), we decided to finally migrate the CDO repositories from SVN to Git.

In this blog entry, I will describe the steps we took to perform the migration. Before starting, however, let me summarize the history of the CDO repository, which leads to some of the specialities we have to deal during the migration.

CDO has been initially created and has lived for a long time in a CVS repository. Thus, we have worked with CVS branches and tags during a long period of our development. Then, the CVS repository has been replaced by SVN and the repository has been migrated and restructured to fit in the new SVN scheme. Also, to make everything cleaner, we have renamed and restructured branches and tags. We have also made use of SVN's capability to organize branches and tags in a hierarchical way (e.g. /branches/maintenance/2.0 or /tags/drops/S20100523-1540). Unfortunately, it became clear that hierarchical branches and tags would cause problems in the build and release infrastructure and so the structure was once again reworked into a flat structure, but this time with a canonical naming scheme to keep tags and branches manageable.

The challenge with SVN is here that it remembers tags and branches as they are at any point in time, even if they do not exist in that form in a later revision. In other words, if an SVN tag (or branch) exists for a particular revision, it will always exist if this revision is checked out later, even though the tag or branch might have been renamed, moved, or deleted in a later revision (and it is, therefore, not "visible" in the repository browser of the current SVN repository). For example, consider a branch in our repository which has existed as sw-rangebased-step1, then as swinkler/rangebased-step1 and finally as swinkler-rangebased-step1, depending on which revision you check out, the branch is still known by one of its older names. For the migration from SVN to Git this means that the migrated Git repository will end up containing all three branches. The same applies to tags as well. 

In addition to this, at some point, three artificial branches have been created in the CDO SVN repository: INFRASTRUCTURE, INCUBATING, and DEPRECATED. The purpose of these branches was to keep projects in the repository, which should not interfere with the main repository, for example, because they contain deprecated code. The additional goal of the migration to Git was to factor out these branches into separate repositories.

But enough talk about challenges, lets dive into the migration process. This process should be executable both locally and on a remote shell. For the CDO migration, an Internet linux server has been used (to have a suitably fast connection for the SVN access). So let's go ... 

Last week I had to debug an Eclipse plugin of one of my clients. The plugin was already instrumented by a few simple tracing output statements here and there, as we know them all:

System.out.println("Entering fooBar()");

Because time was pressing, I followed this example during the debugging process. Afterwards, however, I had some time to refactor the code and I wanted to use the standard Eclipse tracing facility.

I had last used Eclipse tracing a few years ago. Back then, Eclipse tracing was done as described in the Eclipse FAQ by creating a .options file, putting the desired debug and trace options in there, and reading and storing the debug options in fields when the plugin was activated:

public static boolean DEBUG = false;
public static boolean TRACE = false;
 
public void start(BundleContext bundleContext) throws Exception {
	DEBUG = isDebugging();
	TRACE = Boolean.valueOf(Platform.getDebugOption(PLUGIN_ID + "/trace")).
}

In your code, you would then check for the value of TRACE and if the flag is enabled, you print out the message using println as above.

But the API has changed in two ways since then.

Monitoring network traffic is a problem solved a long time ago, one might think. So why write the first entry in my shiny new Blog about monitoring network traffic? Well the answer is simple: because monitoring network traffic is a quite complex topic when multiple components, such as SSL, proxies etc. are involved.

Sure, almost every Linux user knows tcpdump, the intuitive solution for any basic monitoring need. Windows users might think of Wireshark or Proxomitron, for example. And for the Java people, there is at least Apache TCPMon which satifies basic monitoring needs.

All of these tools, however, could not satisfy my requirements: