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

[Stephan Herrmann <stephan.herrmann@xxxxxxxxx>]

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.

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