Well, a simple rule is that the moment the class is in the public (exported
API) you need an exporter.
In the case of Path, you have IPath in the APIs so Path is an implementation
detail and the bundle developer can make its choice. In this case the developer
is likely to import it because he knows someone will provide it when he runs in
Eclipse. However, if I would want to use it in an app also running in netbeans
I might copy it inside because I am not sure who will export it.
Kind regards,
Peter Kriens
On 2 dec 2010, at 19: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.
>
>> 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.
>
>> 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. :-)
>
> 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
