After I got my build working, the next step was making sure that I could update from one product version to the next. I was especially excited about the resolution of https://bugs.eclipse.org/bugs/show_bug.cgi?id=246060 which allows for .qualifier to be replaced in a product version. No longer would I have to manually increment the product version number for purposes of updating to and testing a nightly build.
So my plan was:
- Run PDE product build to generate version 1.0.0.abc
- Unzip 1.0.0.abc to some location.
- Run PDE product build again to generate version 1.0.0.def
- Launch 1.0.0.abc, point it at the repository for 1.0.0.def, and update.
Unfortunately, when I launched 1.0.0.abc, the Install New Software dialog didn't have a way for me to add a new repository. Ditto for the preference page.
Turns out there is a more robust set of p2 UI building blocks in 3.5, which is handy for RCP developers. That is described in great detail here: http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application
I should mention that the RCP-p2 example in 3.5 is leaps and bounds ahead of the one from 3.4 (there wasn't one) - so props to the p2 UI team on that.
At any rate, the wiki page tipped me off that there is a UI policy which controls what components are showing and enabled. This policy is implemented as an OSGi declarative service. What really threw me for a loop is that I wasn't trying to do anything special with this policy. I just wanted the stock SDK one since our product is based on the SDK.
Debugging the Policy Behavior
I stepped through the preference page code and discovered that the
SDKPolicywasn't getting discovered as a service (it was just getting an empty
Policyevery time). So this sent me down the route of launching with
-consoleto see the OSGi console and look for the policy service. After fighting with the filter syntax for the
services <filter>console command, I googled a bit more and found these useful runtime options for spitting out verbose DS logging information. I turned those on but I didn't get anything logged. I was pretty stumped at this point.
Then a light bulb came on: maybe declarative services wasn't running at all? A quick
ss dsat the console showed that it was
RESOLVEDbut not active! I did a
startto spin it up and all of a sudden a deluge of DS logging information printed out. And then
SDKPolicystarted working, and voila my p2 UI was working.
It turns out the root cause is that we had a custom
config.iniin 3.4 to specify a custom
osgi.instance.arealocation. This was screwing up the start level for the ds bundle. I switched the product to generate a
config.inifor me, did a new build, and everything worked. I plan to migrate the
osgi.instance.areaconfiguration step to a
p2.inffile, which is what the platform releng guys do.
 Equinox Runtime Options
 Explore Eclipse's OSGi Console
 Around the world in Java: Getting Started with OSGi Declarative Services
 p2 UI policy bug #1
 p2 UI policy bug #2