On 01/02/2008, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On Feb 1, 2008 1:19 PM, Oberhuber, Martin > <[EMAIL PROTECTED]> 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 > > > > http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html > > > > 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 problems when you mix 'traditional' OSGi bundles with Eclipse plug-ins. BTW, here's an example why Require-Bundle is so inflexible, from Spring-DM: <story> 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. </story> 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: http://aqute.biz/Code/Bnd > 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 > > http://www.eclipse.org/dsdp/tm > > > > -- Cheers, Stuart
