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

With the release Eclipse 3.0, the Eclipse platform migrated the core runtime onto a new OSGI R3 implementation as the basis for its whole plugin framework. The OSGI implementation provides all the low level bootstrapping, plugin classpath management, dependency resolution, APIs exposure control and and whole host of other (currently underutilized) facilities. Eclipse users havn’t noticed the change since it’s all under the hood but Eclipse plugin developers have noticed as the plugin framework is now a little more powerful and metadata can now migrate from the trusty plugin.xml descriptor into an archive’s MANIFEST.MF file, as prescribed by the OSGI specification.

Recently, the OSGI implementation has been promoted to a sub-project of the Platform project and is now publically known as the Equinox project. Effectively they have seperated the OSGI implementation from the rest of the Eclipse platform and now distribute the OSGI framework as one 700k jar. That’s a lot of very useful framework packaged into a very small archive. What got me more interested is that they added a command line interface onto their OSGI framework. Launching it is as simple as:

C:\eclipse\plugins>java -jar org.eclipse.osgi_3.1.0.jar -console

That gives you a little ‘osgi’ prompt:

osgi>

Here’s a hint – enter ‘?’ for help – I’ll not paste it all in here but suffice to say that you can do a lot from that little prompt. There’s lots more at the Equinox quickstart page.

Now here’s where it gets interesting. Java has needed something like this for a very long time and the Java Community Process are starting work on a Java Module System(JSR 277) specification. The initial description of that JSR pointed out that OSGI R3 had some limitations that rendered it unsuitable for consideration. But now Eclipse now supports OSGI R4 – I wonder does it resolve those issues?

I expect to see OSGI play a larger and larger role in Java library/application packaging and distribution in the future. However, OSGI really only provides benifits if the packaged code is modular and easily pluggable. Monolithic messes that cannot be decomposed into multiple bundles will not gain as much benifit.

aehso eclipse, software

I’m still catching up on yesterdays news. Macromedia announced that they are are going to move their Studio tools onto the Eclipse platform. With Borland announcing a similiar move for JBuilder last week it would appear Eclipse has now reached critical mass in terms of mindshare as the tools platform of choice for enterprise development (the anti-Visual Studio.NET as I sometimes think of it)

Expect the political infighting to increase in the Eclipse Foundation as the new platform members start attempt to drop un-Eclipse type requirements on the Eclipe core development/architecure team in a bid to ease their internal migration costs.

Apple, be advised – start putting more effort into improving the performance of Eclipse/Java on OS X or the “creative types” will switch to Wintel to run Macromedia’s tools.

aehso eclipse