The build ran fine, but the previous build's consuming bundle was used when creating the update site (since we didn't tag that bundle, the qualifier did not change).
When an unsuspecting co-worker updated to the latest build, his system would no longer start at all with a number of java.lang.NoSuchMethodErrors.
So how do you fix your install, given that you can't even bring up the workbench? As it turns out, p2 can help you. The SDK profile saves its state on each installation change. You can usually find this information in:
bash-4.1$ ls eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile 1299467192263.profile.gz 1299499722731.profile.gz 1299761082054.profile.gz 1299467192395.profile.gz 1299499723473.profile.gz 1299761705917.profile.gz 1299467285942.profile.gz 1299499764937.profile.gz state.properties 1299467287251.profile.gz 1299500329056.profile.gz
Then you just need to pick the last stable version of your installation, and you can revert your install and restart your system.
eclipse/eclipse -noSplash \ -application org.eclipse.equinox.p2.director \ -repository file:$(pwd)/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile \ -profile SDKProfile \ -revert 1299499722731
Obviously you'll need to use a different eclipse install and the necessary -destination arguments if the corrupt bundle is *in* the director part of your install's p2 framework :-)
The director won't run this command without specifying a -repository, but it's not important which one you use so I used the installations own SDKProfile repository.
For more director information see p2 director.
