[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [orbit-dev] FW: Support for OSGi
|
The thread at http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html has surfaced an issue in the OSGi specification which I have surfaced to OSGi. I opened an Equinox bug to track this discussion. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=217724
In short, I think the specification needs to be changed such that substitutable exports (the practice of exporting and importing the same package) does not have adverse effects on require-bundle clients.
Tom
"Oberhuber, Martin" ---02/05/2008 08:13:43 AM---FYI - Why Apache Commons wants to keep using Import-Package
![]()
From: | ![]()
"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> |
![]()
To: | ![]()
"Orbit Developer discussion" <orbit-dev@xxxxxxxxxxx> |
![]()
Date: | ![]()
02/05/2008 08:13 AM |
![]()
Subject: | ![]()
[orbit-dev] FW: Support for OSGi |
FYI - Why Apache Commons wants to keep using Import-Package
instead of Require-Bundle. I found the Spring DM / RCP /
Commons Logging Story very interesting.
I'll happily forward any comments to the Apache Mailing
Lists, since I find these different views on the subject
very interesting...
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
-----Original Message-----
From: mcculls@xxxxxxxxx [mailto:mcculls@xxxxxxxxx] On Behalf Of Stuart
McCulloch
Sent: Freitag, 01. Februar 2008 17:56
To: dev@xxxxxxxxxxxxxxxx
Cc: Commons Developers List; Orbit Developer discussion
Subject: Re: Support for OSGi
> > http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00627.html
> >
> > 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.
Cheers, Stuart
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev

