[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Class visibility without declared dependency
|
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
package.
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 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.
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.
cheers,
Stephan
