On 12/2/10 13:04, Jeff McAffer wrote:
Can you not see that Path would be defined as a utility or not by the bundle
that uses it?
Give me some credit. Of course.
Well, you appear to be wanting to classify a given class as globally a
utility or not, but this depends on how it is used.
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.
But this still begs the question of how should people make available the "utility"
(english meaning of the word) classes that are being shared. Should they be in one bundle? Should
each bundle have its own copy but import/export and use "uses"? System designers still
face this question.
Of course. I can't given a definitive answer where none exist. I've
already stated that there is no single answer for this. It just depends.
We can only give them some rules of thumb and they need to decide for
their own situation.
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.
Its not dumb. it doesn't work. :-)
Creating something that doesn't work sounds dumb to me.
-> richard
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
