commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <>
Subject Re: Support for OSGi
Date Fri, 01 Feb 2008 16:56:08 GMT
On 01/02/2008, Niall Pemberton <> wrote:
> On Feb 1, 2008 1:19 PM, Oberhuber, Martin
> <> wrote:
> > Hello Niall / Stuart,
> >
> > thanks for your answers. It looks like the usage patterns
> > of OSGi in the Apache and Eclipse communities are just
> > a bit different: Apache focuses on packages whereas Eclipse
> > focuses on Bundle granularity for Re-use.
> >
> > That's why we don't explicitly import all exported packages
> > at Eclipse -- we're using Require-Bundle instead of
> > Import-Package throughout our system, mostly due to the way
> > Eclipse Plugins have been workign in the past. For details,
> > see also
> >
> >
> >
> > What does that mean in practice?
> >
> > 1.) Looks like we Eclipse folk will need to continue writing
> >     our own OSGi Manifests for some time since the
> >     "Require-Bundle" vs. "Import-Package" patterns do not
> >     mix too well.

True - of course, if you have several bundles exporting the same package(s)
but not importing them, then while this means Require-Bundle will be more
predictable, it also means that you're more likely to see class cast
when you mix 'traditional' OSGi bundles with Eclipse plug-ins.

BTW, here's an example why Require-Bundle is so inflexible, from Spring-DM:

   Spring-DM uses the commons-logging API, but not the implementation
   because it doesn't work well with OSGi classloading (see the Spring-DM
   FAQ for more detail). People usually use Pax-Logging or other adapters,
   which is possible because Spring-DM gets the API using Import-Package.

   Recently a developer using Spring-DM and Eclipse RCP reported a logging
   problem (he saw the usual exception when using the commons-logging
   implementation) so we suggested he switched to another adapter.

   Unfortunately he was also using the commons-discovery bundle (I think
   from Orbit?) which has a Require-Bundle for commons-logging. This hard
   dependency meant he couldn't substitute another logging bundle, while
   he could have done if Import-Package was used.

   In the end he re-bundled commons-discovery to use Import-Package
   which fixed the problem, and he now has Spring-DM working with RCP.

Given that commons bundles will be used by the wider community then IMHO
they should use the Import-Package approach - hopefully plug-in developers
will start using it over Require-Bundle (at least for commons packages).

It would have been good to meet everyone's needs but from the link you
> posted and what Peter and Stuart have said in this thread then that
> doesn't seem possible and from my limited perspective it seems clear
> that we (in Commons) should follow whats considerd good OSGi practice
> rather than those of eclipse.
> Niall
> > 2.) Whenever somebody converts an auto-generated OSGi Manifest
> >     into a manually maintained one, it's worth thinking about
> >     a) What packages are really API and thus worth being
> >        exported, versus what packages are considered internal
> >        hidden implementation;

Actually with Bnd, you tell it which packages to export and which to keep
private - it's just that most commons projects will start by exporting all
packages, then over time mark some as private. Some commons jars
may also need Bundle-Activators to manage life-cycle issues, such as
background threads, etc. under OSGi.

You can read more about Bnd here:

>     b) What packages are expected to be potentially split
> >        across multiple bundles, or would always reside inside
> >        the same bundle.

Again, while Bnd allows split-packages (with a warning) they are usually
not recommended from a 'traditional' OSGi perspective as they quickly
turn into a management nightmare.

FYI, SLF4J used to use split packages, but they refactored their jars to
avoid them, and it solved a lot of issues.

> > Or am I missing something?
> >
> > Thanks,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> >
> >
> --
Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message