As some of you know, Eclipse 3.4M6 is on the horizon. This is going to be a big and important milestone as it contains a revamped update (provisioning) system called p2. This is a crucial move for Eclipse as the old Update system which I was intimately familiar with (IFeature.STATUS_UNHAPPY anyone ;p) was antiquated… it was around before OSGi was put in as the basis of the Eclipse runtime. It’s time for a change…
What do you need to know? Well, p2 is pretty advanced compared to Update and the p2 team has done a good job with wiki-based documentation. However, for end users, there will be fairly little change in terms of what you see. The two most important things for end users I can think of is the work of creating a simpler Update UI (a work in progress) and a workflow change in how you add plug-ins to Eclipse. Do you remember that old technique of just dropping plug-ins in the plugins directory and having the old Update promiscuously install them? p2 has matured a bit and is less promisicous… however, there’s is a new ‘dropins’ folder where you can put your update sites and zip files:
The 3.4M6 release of Eclipse also signifies time for some penance. We have sinned against one of the greatest software engineering principles… eating our own dog food:
In the past, most people when they moved to a new version of some Eclipse project… we simply grabbed a new zip… unpacked it along with a new SDK or used the clever technique of link folders.
This is wrong.
It’s time to be using the p2 facilities to perform simple build-to-build updates. I have been doing this with the SDK recently and it works out nicely. When there’s a new update, I simply get the files I need using p2 and it does all the magic for me. The saying is that “old habits die hard,” and this is one habit that needs to change. In order to ensure the success of p2, it’s time to start eating our own dog food when it comes to updating plug-ins.