On Aug 2, 2008, at 10:27 AM, BJ Hargrave wrote:
So we have:
foo:
Export-Package: a,b;uses=a
Import-Package: a
bar:
Import-Package: a, b
car:
Export-Package: a
Thus we have 2 exporters for a and one for b. Who ever imports
should use the same a that foo uses.
So we can have
1) car exports a. foo exports a and b. bar import a and b from foo.
(No one uses a from car.)
2) car exports a. foo imports a from car and exports b. bar imports
a from car and imports b from foo.
> bar can wire to foo's "b" and car's "a" package. Won't that cause
a problem?
This should not happen because of the uses constraint. This is the
whole point of the uses constraint on the resolver.
Let's say that foo and car are installed. Foo gets resolved and uses
its "a" export to satisfy its "a" import; car does not get used.
And so we're back to what 3.7 means by discarding the import. If the
import is discarded then there's no wire. If there's no wire then
there's no information to support the "uses" directive. If there's no
"uses" directive then there's no "uses" constraint.
Now bar gets wired. There's no constraint to tell it to use foo and
not car to wire "a".
Regards,
Alan
--
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 Developer Mail List <[email protected]>
Date: 2008/08/02 01:02 PM
Subject: Re: [osgi-dev] Bundles importing and exporting the same
package
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
_______________________________________________
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
