Re: [equinox-dev] Class visibility without declared dependency

[BJ Hargrave <hargrave@xxxxxxxxxx>]

> 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 hargrave@xxxxxxxxxx

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