[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 18:45:55 +0100
- Delivered-to: email@example.com
On Sat, Jul 27, 2013 at 5:20 PM, Stephan Herrmann
> On 07/27/2013 05:48 PM, BJ Hargrave wrote:
>> You should also set mandatory:=my-attr on each export of provider so a
>> hapless importer does not import some random subset of your
> Makes sense, thanks.
>> 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
>> 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.
> No problem, here's the motivation again:
> While moving from Kepler to Luna I'm forced to require package exports
> that are redundant with information we already have in an extension point.
> If I can't avoid the exports I might as well try to use them *instead* of
> the extension point. So, to avoid the redundancy I'm thinking of enriching
> the export headers so that the extension point is no longer needed.
> Given that the information in the extension point is quite detailed,
> putting all this into a single Export-Package entry would be messy
> (think of an attribute value spanning tens of lines).
> For those reasons I'm experimenting with splitting a package export
> entry into multiple entries to the end that each entry comes down
> to manageable complexity. Given that I need to declare some details
> per class lead me to defining exports at that level of granularity.
> IOW: it's not my paranoia about individual classes seen by some
> bundle that shouldn't (that's only extra safety which I consider
> nice to have, but not a driving force) but now it's a quest for
> a structure for declarations that are both redundancy-free and
> comprehensible, while capturing all necessary details.
> If package-export can be used to piggy-back my additional
> declarations, then my problem is solved, if package-export proves
> to be unsuitable for this task, then I'm back at square one.
I think that the Export-Package header is unsuitable for this, but
you're not necessarily back at square one. You should probably look at
the generic Provide-Capability header instead.
The Eclipse extension registry is an instance of the "extender bundle"
pattern, and since around OSGi R4.3 it was decided that we should
generally try to use Provide- and Require-Capability to model the
pattern rather than either arbitrary manifest headers or resources
inside the bundle. Provide-Capability should support all of the
attributes that you want to express, and furthermore you can take
advantage of Require-Capability to create dependencies on those
capabilities/attributes. These dependencies would be visible to both
the OSGi Framework resolver and to other resolvers such as the OBR/R5
resolver Perhaps in the future p2 will support them too.
> equinox-dev mailing list