Friday, January 15, 2010

P2 or why I can't sleep anymore

In the next one and a half year we are going to build a huge RCP for Switzerlands leading car sharer. They insisted to build a web frontend. We said that there is no way we are going to implement the beast they want in a web technology. They agreed under the condition that our rich client is able to update itself once deployed. I thought no problem: there is this new fancy updated mechanism called P2. This was about the time when I've started to worry and stopped sleeping.

Adding P2 self update to your RCP

There is a nice tutorial explaining how to convert your existing RCP to become a self updating P2 enabled RCP here:

First I had to change my hudson build to build a P2 enabled RCP. We use the plugin builder to configure the PDE headless build scripts. Even with the plugin builder it is far from trivial to set up a headless build. But once you get used to it it works quite well. Unfortunately the plugin builder doesn't seem to support P2 enabled builds. So I had to mess a bit around with the ant scripts. But after a day of swearing and sweating I was able to get it to work. Ok, the build now takes about twice as long as before but who cares?

Next step was to add the P2 dependencies to the product, by adding the p2.user.ui feature. This worked quite well. The RCP now is only like 30 Megabytes larger but who cares?

Next step was to add the check for update action as described in the above tutorial. This action is only about 100 lines long and uses almost exclusively internal P2 code plus it doesn't work out of the box because of this bug. But who cares?!

Now, I've increased the version number of the product, a feature and a plugin. Then I've add the location of the P2 repository which my brave little hudson builder crated as a touchpoint to the p2.inf file. For a start I've chosen to use a local repository located somewhere in my file system. All what's left is to start the old RCP and off we go with the automatic update! Yeah, whatever. It didn't work. Nothing, no update, no exception, no nothing. I've started to care!

I've played around with it, several hours, googled, read forums, read the p2 equinox wiki. I've added the P2 update UI to my RCP and realized that it actually found the update site but did refuse to update. Then I made an interesting discovery: If I created the p2 repository by exporting the product with my local eclipse install and used this repository it worked!


I assume something, no idea what, is wrong with my headless build. I thought ok, I can life with that for now: I only have to export the site every now and then. All what's left is to add the repository to some web server and point a touchpoint to the repository URL. Guess what: Didn't work! The exact same repository: If located in the file system it works, if added to a web server it doesn't. What's this good for!?

No, it doesn't work!

I had a tough night, got up at 4 o'clock in the morning and couldn't sleep no more. It was time to visit our CTO.


Our CTO is a unix hacker, he likes scripts and configuration files, he thinks that a console is a more then sufficient user interface (they even have copy paste support nowadays you know). He doesn't like frameworks and of course he hates Java. He said: Fuck that shit! You want to update your RCP? Just make your RCP download a self extracting zip file, close the RCP, execute the self extracting zip file in the install folder and start the RCP again: Voila! Know what: This sounds like a hack but there is a golden rule when writing software:
And his approach does the Job. We can even update the JRE which we ship with the RCP (not like P2 that tries to delete the JRE while the JRE is still used which of course doesn't work on windows).

But self extracting zips have some drawbacks:
  • We couldn't find an easy way to generate them for windows with our linux build server
  • You can only add files and not delete files.
  • They only work on windows (not a problem for us though)
We found this nice open source project: InstallJammer. With InstallJammer you can:
  • build windows installers with linux.
  • execute various actions on install, including deleting files
  • run the installer in silent mode such that the user doesn't realize that what is executed is actually an installer
  • start your program after the installer has finished
  • build installers for windows, linux and they say osx support is coming soon
The next night I've slept like a baby.


Here is my advice: If you need to update an RCP which you control, which can not be extended by users, then do not get into the P2 businesses. That's my opinion. I know it is possible to use P2 for this and I know there are people which used it successfully. But I like solutions which I can control and understand, and P2 I can not.

In a next post I will explain a bit more in detail how we did it with the installer approach.


  1. Benno, did you ask for help on the p2-dev list or open bugs with the RT->Equinox->p2 bucket for your issues?

  2. Hi Benno,

    I'm from Switzerland too, and working on a Eclipse based project too. ;)
    Why not java webstart?
    Eclipse supports exporting and jnlp file generation.
    We are using it on a small number of user cause we are in beta stage, but seems that everything work perfectly.

    I'd like to know your opinion. Kindly
    E. Dominguez

  3. Kim, I did not. The problem is that I don't know what to ask. If there where an exception or some useful error message I'd ask. I could attach the source of my complete product including build scrips to a general "doesn't work" bug if this helps? But the core of the problem for me at the moment is that auto update is mission critical and I need a solution which I understand and can fix if I have to.

    Elvisd, i guess one could also build something like the installer aproach with webstart. But don't you have restrictions what a webstart app is allowed to do in de local file system? Can you start the workbench just like this?

  4. Hi benno. If you sign your jars the a webstart application can do whatever you like on the filesystem.
    We are deploying in these days the application for 20 users, but they will be many more. till now no problems.
    Try it when you have some time... ;)
    Hope this can help you

    Kindly from Ticino

  5. Hi Benno,

    Kai has done a great application illustrating the p2 self update mechanism (see and It's worth taking a look at those examples to see if it can help you - in the long run, the p2 approach is probably best.


  6. Hi James, thanks for the links. I did look at it, that's how I found out about the touchpoint stuff.

  7. I do believe you are sleep deprived.
    There can't be 31M of overhead given that just the eclipse platform download is 46M and includes p2. As for the build time goes, I believe that you must be first creating the final archive to then generate p2 metadata from it and eventually get a p2-enabled archive to be created. For all it worth, the p2-ization of the Eclipse build process itself shaved some significant time of the build process.
    As for the JRE, this is definitely a problem and I would suggest putting the JRE in a new folder everytime since the JRE is running.

  8. Pascal, you are correct about the 31M overhead. It was just that I had a very minimalistic RCP and the p2.ui feature pulled in a lot of the platform. But since I'm going to need the platform anyway it's not a p2 problem. My bad.

  9. If you're looking for a light weight OSGi dependency resolver you may be interested in Nimble [1] the core download of which is a 55Kb launcher. Nimble also provides a console shell environment that offers scripting support so should make your unix hacker boss happy :)

    There's some blogs about it's capabilities here [2] and [3].




  10. Benno, with respect, if you had engaged with the p2 team with your problem you might have been able to help you with your problem without a negative blog post. They are very helpful people :-)