[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Class visibility without declared dependency
- From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
- Date: Sat, 27 Jul 2013 17:35:47 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
On 07/27/2013 05:12 PM, Neil Bartlett wrote:
Quick experiments with Export-Package & include seem to indicate,
that from multiple exports of the same package only the last one survives.
What kind of experiments?
Activator uses classes provider.C1, provider.C2, provider.C3.
Only C2 is found at runtime.
But I see now that this is an incomplete experiment, see below.
Export-Package can indeed export the same package multiple times with
different attributes. For example it's possible to exports multiple
Export-Package: org.foo; version=1.0, org.foo; version=2.0
and this bundle can be wired by importers importing either version
[1.0,2) OR [2.0,3). That is, the importer may match any one of the
exports, they do not need to match all.
Maybe the problem is at the import side, not the export side.
When I modify the client declaration:
then C2 is no longer found, but C1 is. Makes sense.
I had implicitly hoped that omitting my-attr would lead to importing
the merge of both export declarations. This seems not to be the case.
I interpret this as:
- a bundle may multiply export the same package with different attributes
- a bundle can import the same package only once, selection will be based
on attribute matching (or s.t. like last-save-wins if attr. not specified)
Please correct me if this is wrong.
This gets me thinking how I can group the necessary declarations
so that each importing bundle will find a matching and exhaustive