[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Class visibility without declared dependency

> From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
> >
> > What kind of experiments?
> bundle Provider:
> Export-Package: provider;include:="C1";my-attr="foo",
>   provider;include:="C2";my-attr="bar"
> bundle Client:
> Import-Package: provider
> 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
> > versions:
> >
> >      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:
>    Import-Package: provider;my-attr="foo"
> 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
> export declaration.

You should also set mandatory:=my-attr on each export of provider so a hapless importer does not import some random subset of your package.

But this whole thing seems like overkill. Why don't you simply export the whole provider package and have the importers import the whole package. Packages are a unit and should be shared as a unit. The include/exclude directive was put in place to handle stupidly designed packages with public implementation types the should not be shared.

I admit to not having followed this thread extremely closely, but I don't recall any justification for what you are proposed (exporting a single class from a package). Just because something can be done does not mean it should be done.


BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the
OSGi Alliance

office: +1 386 848 1781
mobile: +1 386 848 3788