On Aug 2, 2008, at 9:30 AM, BJ Hargrave wrote:
A bundle can either export OR import a given package name. A
bundle's import is never resolved to its own export. There is mutual
exclusion here.
So in your example one of 2 cases will occur:
1) the bundle will export a and b. Any classes within the bundle
which want to use classes from a or b will use a and b from inside
the bundle.
Let's call the previous bundle foo. So, I have bundle bar:
Import-Package: a, b
and bundle car:
Export-Package: a
bar can wire to foo's "b" and car's "a" package. Won't that cause a
problem?
Regards,
Alan
2) the bundle will export b and import a. Any classes within the
bundle which want to use classes from a will use the imported a. Any
classes within the bundle which want to use classes from b will use
b from inside the bundle.
The uses class for b (b; uses:=a) means that any bundle which import
b (which does include the example bundle since it does not import b)
should use the same a that the bundle from which b was imported
uses. This should be quite easily met in your example.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Alan Cabrera <[EMAIL PROTECTED]>
To: OSGi Mail List Developer <[email protected]>
Date: 2008/08/02 10:49 AM
Subject: [osgi-dev] Bundles importing and exporting the same package
If I read section 3.7. correctly, when an import gets resolved
internally to its own export that overlapping import is discarded. I
take that to mean that the wire does not get created. If I am correct
then it seems that in certain cases, package constraints are not
properly adhered to.
If we have a bundle:
Export-Package: a,b;uses=a
Import-Package: a
When the import of "a" gets resolved internally to its own export of
"a", that overlapping import is discarded. There's no wire to
constrain users of package "b".
I may misunderstand something here.
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
