On 12/2/10 12:27, Jeff McAffer wrote:
On 2010-12-02, at 11:29 AM, Richard S. Hall wrote:
Well, one thing is clear, if classes appear in your API, then you clearly
expect bundles to collaborate around those classes, so having a bunch of
bundles embedding there own copies of these classes would be really dumb since
none of them would be compatible with each other.
I think you have to differentiate between classes for collaboration and
"utility" classes (i.e., ones not for collaboration).
Which is Path? (Path is an Eclipse class used for representing and manipulating filesystem-like paths) To many it is
simply used internally because it has lots of great helpers and "does it right" for off the wall cases. For
others it is exposed on their API as a arg/return type rather than forcing rock/stick programming. Should some people
embed Path in their bundle while others share one implementation? For those who share, where does the implementation
go? A common "datatype" bundle? :-) If everyone embeds is that "really dumb" or the intended
purpose of the "uses" clause?
Can you not see that Path would be defined as a utility or not by the
bundle that uses it?
If I use Path, but it is not exposed in my API, then I can treat it as a
utility class. That doesn't prevent other bundles from treating it as a
shared class. It just means we might not use the same version among all
bundles, but for those embedding it because it is not exposed via their
API, this will cause no issues whatsoever for them, nor the sharing bundles.
And if you have a bunch of bundles intending to collaborate around a
given set of types and they all embed their own copies and don't
import/export them (i.e., make them substitutable), then it is really
dumb. You can only collaborate through shared types. The intended
purpose of "uses" constraints is to make sure that is so.
-> richard
Jeff
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
