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 _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
