Aehso’s Output

Since the introduction of the new OSGi core in Eclipse 3.0 I’ve noticed a couple of quirks that manifest themselves when I am developing and testing plugins via a runtime workbench. A couple of days ago I ended up summarizing some tips in an email to a friend but I think they’ll be useful to others too so here you all go:

• While working on plugin source code, do not leave old binary builds of the plugins that you are working into the Eclipse installation’s plugins/ folder. Having the plugin project in your development workspace should mean that the runtime workspace will load the plugin from your project but this doesn’t completely work. From my experience, the runtime workbench will pick up the new classes from your project but the OSGI implementation does not recognise changes made to the MANIFEST.MF file (for example, new bundle dependencies introduced etc). I believe the problem is related to the fact that Eclipse holds it’s cache of OSGI manifest information in <eclipse>\configuration\org.eclipse.osgi\bundles which is being shared by both your development and runtime workspaces (and therefore the runtime workbench “sees” OSGI info it shouldn’t).

  To fix this:

  1. Delete the installed plugins. Let the dev workbench projects supply the code to the runtime workbench.
  2. Delete the contents of <eclipse>\configuration\. Leave the config.ini file there! Alternatively you can run eclipse -initialize from a shell in the Eclipse installation directory. The process should appear busy for a second (as it cleans the configuration caches) and then exit quietly.
  3. Restart Eclipse. The first restart will be a bit slower as it needs to rebuild the OSGi caches.

• The workspace metadata can get out of sync with reality if you manually tinker with the plugin.xml and/or the MANIFEST.MF files in the back-end <eclipse>\plugins\ folder. If you see build errors when attempting to run the Export Plugin wizard that do not show themselves when building inside the workbench then this is your problem. Again, it’s slightly related to the above – I believe the <workspace-dir>\.metadata\.plugins\org.eclipse.pde.core folder contains dependency info that is out of sync with what exists on the file system.

  To Fix, deleting everything in the <workspace-dir>\.metadata\ folder usually works. Deleting the metadata effectively cleans the workspace. Be warned though – the workbench will have forgotten what projects you had in the workspace and what preferences you had changed. Here’s a hint: either get used to the default preferences (they are appropriate for “good” Java development) or get used to exporting/re-importing your preferred preferences set (inc. team repository, JDK info etc.) whenever you clean/create a workspace (see File->Export/Import->Preferences

• Import your projects into a workspace from an “external” folder (a CVS root folder for example). Generally it’s not a good idea to store project source in the workspace folder unless they are temp/demo projects that you can afford to loose at any time.
  Keeping your project resources external to the workspace means there is a cleaner separation between local workspace junk (scrap projects) & state (.metadata) and the more important shared/versioned product source code.
  It also means you can have several workspaces that are looking at the same code base. For example, I have six workspaces importing different sets of projects that are stored in just two CVS snapshots. (I only ever use one or two concurrently!)
• Rather than copying packaged plugins into the \plugins dir, create a <eclipse>\links\my-drivers.link file (A driver is common eclipse.org developer speak for a binary distro of plugins). In that file, add a single name/value ‘path’ property – something link
  
path=C:/build/_output

  Note the mechanism assumes that “_output” above contains an “eclipse\plugins” sub directory that in turn contain the extra plugins it should load (typically your build output).
  NOTE: if you use this you have to be careful – any time your build output changes, you must remember to run “eclipse -initialize” or the OSGI caches won’t be in sync with changes.

aehso eclipse