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

[Neil Bartlett <njbartlett@xxxxxxxxx>]

On Sat, Jul 27, 2013 at 3:53 PM, Stephan Herrmann
<stephan.herrmann@xxxxxxxxx> wrote:
> On 07/26/2013 11:15 PM, Thomas Watson wrote:
>>
>>
>>  > If OSGi would support Export-Class we could simply augment that
>> declaration
>>  > for our purposes :)
>
>>
>>
>> I think this was mentioned before, but not sure if I heard why it cannot
>> be useful for you.  There are directives include/exclude
>>
>> [1] that allow an Export-Package to specify particular classes that should
>> be exported.  For example, if you only want to export the
>> classes X and Y from package foo:
>>
>> Export-Package: foo; include:="X,Y"
>
>
> This is very close, but no cigar, I'm afraid.
>
> As I'm in favor of also migrating our extension point-based declarations
> to new manifest headers, let me sketch what a declaration for OT/Equinox
> might look like, if we'd piggy back on Export-Package to avoid redundancy:
>
> Export-Package: foo; include:="Team1"; ot-adapts-base="bundle2";
> ot-activation="ALL_THREADS",
>  foo; include:="Team2"; ot-adapts-base="bundle3"; ot-activation="NONE"
>
> The point is: a package may contain several team classes, each of which
> needs specifying details (like what bundle to adapt and activation at
> start-up).
>
> 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?

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.

However when you use the include/exclude directive, my intuition is
that the filter would only apply to the actual export that is wired by
each importer. Tom would probably be able to confirm this.

>
> Is this the intended/spec'd behavior or could the above example be made
> to work? Can OSGi cope with multiple exports of the same package just
> with different attributes?
>
> If it were possible to make one export declaration per team class
> then the approach might actually fly, but specifying nested structures for
> tens of team classes inside a single export package entry doesn't feel
> right.
>
> thanks,
>
> Stephan
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev