[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Class visibility without declared dependency
- From: Neil Bartlett <njbartlett@xxxxxxxxx>
- Date: Sat, 27 Jul 2013 16:12:49 +0100
- Delivered-to: firstname.lastname@example.org
On Sat, Jul 27, 2013 at 3:53 PM, Stephan Herrmann
> On 07/26/2013 11:15 PM, Thomas Watson wrote:
>> > If OSGi would support Export-Class we could simply augment that
>> > 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
>>  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";
> 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
> 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
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
> equinox-dev mailing list