Thursday, March 10, 2011

A working state from a p2 update

In one of our recent build/update cycles we made a change that was source compatible but not binary compatible.  In this case (there are no errors anywhere) it's easy to miss that you need to tag the consuming bundle as well.

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
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.