First, do not mix up the JREs and the deployed RCP application. SWT exists for 32 Bit and for 64 Bit – use the appropriate version with your JDK. If you run a 64 Bit JDK, use the 64 Bit Eclipse Helios version, same with the 32 Bit versions. The deployed RCP application will also be 64 Bit and 32 Bit respectively, because the files are copied from the IDE during the deployment process. If you mix up between them you will run into errors like this:

!SUBENTRY 1 org.eclipse.osgi 2 0 2010-08-05 13:59:28.417
!MESSAGE Bundle org.eclipse.swt.win32.win32.x86_64_3.6.0.v3650b [56] was not resolved.
!SUBENTRY 2 org.eclipse.swt.win32.win32.x86_64 2 0 2010-08-05 13:59:28.419
!MESSAGE Platform filter did not match: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86_64))

and/or this:

Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.SWTError
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(Unknown Source)

But I found myself in a situation where even the correct version of the JRE (64 Bit in my case) didn’t work together with a deployed RCP application from a 64 Bit Helios IDE. The default launching arguments (which can be found on tab “Launching” in the product configuration) are set to:

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog -debug

Unfortunately the placeholder do not seem to be resolved during the deployment. Therefore they end up in the generated eclipse.ini, which looks like this:

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.0.v20100503
-os
${target.os}
-ws
${target.ws}
-arch
${target.arch}
-nl
${target.nl}
-consoleLog
-debug
-noexit
-vmargs
-Xms40m
-Xmx384m

The launch of the RCP application fails, obviously because a system architecture called “${target.arch}” does not exist. Setting the parameters manually resolved finally the problem – although it took me 2 days to figure out what the actual problem was. I suspect that this is a bug in Helios. Here’s what the eclipse.ini should look like:

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.0.v20100503
-os
win32
-ws
win32
-arch
x86_64
-consoleLog
-debug
-vmargs
-Xms40m
-Xmx384m

Simply omitting the operating system parameters will also work:

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.0.v20100503
-consoleLog
-debug
-vmargs
-Xms40m
-Xmx384m

The next step of course was restoring the data from the backup drive. For backup purposes I use Time Machine, the OS X built-in backup solution by Apple. Time Machine is able to create an OS X installation on a blank disk by accessing the backed up data. All my backup data resides on a Network Attached Storage device. For far, so good, should work like a breeze. At least that’s what I thought. The first attempt to restore my data failed, and so did the second and the third. On a first look, it seemed that Time Machine was not able to read some Japanese help files of iPhoto. Although I don’t care about the Japanese help there does not seem to be a way to exclude certain files from being restored. However, after examing the log files of the restore attempt a little closer, it turned out that the Japanese help wasn’t the one to blame. Time Machine itself is the bad guy – it crashes because it seems to forget to turn off the Standby mode of the Macbook while restoring. I was able to reproduce the behaviour: as long as I move the mouse pointer the restore process keeps on running, but as soon as the screen blanks (the default is 10 minutes), Time Machine crashes!

After searching for a while on the Internet I finally found a solution – I didn’t want to go the obvious way: sitting in front of the laptop for a couple of hours, touching the mouse every 5  minutes. It is possible to set the configuration for power saving via the command line. Before starting the restore job, start the terminal. The tool that saved me is pmset, which lets you set the time until the screen blanks and the disk is turned down. However, a simple

pmset -a  displaysleep 3 disksleep 600 sleep 600

fails, because pmset is not able to write the configuration data (which is not very surprising, when booting from the installation DVD). Used with the force option makes things better:

pmset -a  displaysleep 3 disksleep 600 sleep 600 force

however, Time Machine is still crashing, this time after 3 minutes when the screen goes blank. Only a

pmset -a  displaysleep 600 disksleep 600 sleep 600 force

which keeps the laptop awake for 10 hours seemed to help. But I was wrong: after several hours and around 65 % of the job done Time Machine crashed again, out of the blue. I suspected that it might have something to do with my NAS. I’m not using the official Apple solution Time Capsule but a Synology DiskStation 207+. This NAS can act as Time Capsule replacement having Time Machine support, but maybe some certain feature is not implemented well?

The next step was to try to install from a USB drive instead from the network share. So I copied all Time Machine data from the NAS to an external USB drive. This took about 10 hours. Next installation attempt, this time from the USB drive. The result: same story as before. Time Machine worked for a couple of hours and crashed in the middle of the restore job. What to do next?

The MAC OS X installer offers a so-called migration assistant which is able to migrate data from a Time Machine backup. So I installed Snow Leopard. During the installation the user is asked about migrating data, both from network and from a USB drive. And both methods didn’t work. The network variant didn’t because the migration assitant was not able to access the Time Machine backup. It tried but failed, telling me “unable to access data”. A funny thing: the button that triggers the connection to the network device is disabled after the first try. If you enter a wrong password for the network share – bad luck, you don’t have a second try. The backup on the USB drive wasn’t recognized at all. In addition you cannot influence the detection, it is not possible to tell the migration assistant “Look in this folder!”.

The migration assistant can also be started after installation. This time the USB drive was sucessfully detected and the data could be restored from there. Only one important thing: you need to create a user during installation that is named differently than the one saved in the Time Machine backup. Otherwise the user dat cannot be restored. I created a different user after the installation of Snow Leopard was finished. The migration assistant needs to be started from that account in order to overwrite the account that exists both on the machine and in the Time Machine backup.

Finally that’s the end of the story, end of this nightmare. I somehow sense that nobody at Apple ever tried to actually perform such a restore job. Overall I’m quite disappointed of Time Machine. The story took me one whole week. I’m glad that this was only my private laptop – imagine if this was my business laptop and I would have relied that!

Yesterday I experienced a new business process at the Leipzig main station. I was in need of a ticket from the airport back to my home town, which (for some unknown reason) cannot be bought at a ticket machine. So I needed to approach someone at the counter. But I had to learn that things have changed. It is not possible any longer to approach someone at the counter. Now the lonely traveller has to pull a numbered ticket from a new number ticket machine (A new machine! Somehow I feel, that this is not a coincidence …). Above the counters there are brand-new screens which tell you what numbered traveller is next to be allowed to approach the counter. Unfortunately this leads to much longer waiting times than before, mainly because people tend to pull a ticket, notice that waiting for their number to be called takes too long and leave. In turn, this leads to counter assitants sitting there and waiting for “their” traveller with the right number (who already left). I had the funny situation that the majority of counters had no traveller in front of them to offer its service although there were plenty of them waiting to be called … In addition, travellers hang around in the counter hall, waiting and doing other things which leads to the case that it takes quite a while for most people to find out that their number has been called and which counter is the one to be approached. I wonder if one should carry out a scientific investigation on how much the waiting time has increased …