Hi Peter, That is indeed an interesting option! And indeed leads to the possibility for a kind of "atomic" dependency view on e.g. the ReporterAdapter extension.
thanks for the info erwin On Thu, Jan 31, 2013 at 10:33 AM, Peter Kriens <[email protected]>wrote: > There is one trick in bnd that can solve your problems but it requires > that you're very careful not to expose the base classes/adapters outside > your bundle. It is called Conditional-Package, it is similar to static > linking in C. > > What you do is provide the base classes in a special package subtree (I > use aQute.lib). In the bnd file you do: > > Conditional-Package: aQute.lib.* > > bnd will now automatically copy the classes in these packages that you > actually use into your bundle and not export them. However, you have to > make sure these classes never are visible in the API. For example ... > > I have a aQute.service.reporter.Reporter interface that is used for > reporting progress, errors, warnings, etc to users. I have a > aQute.lib.reporter.ReporterAdaptor that implements this interface. Whenever > I have a class that does reporting I often extend ReporterAdapter since > this is just awfully convenient. However, I do not require a support bundle > (which often become dependency hell) since the aQute.lib.reporter package > is automatically included in my own bundle. > > Interestingly, this was how ar(chive) files worked with C. We had a period > where we turned to dynamic linking but it is interesting to see how are > moving back to solutions that carry all their dependencies (WARs, Apple App > store, Microsoft, etc) since the dependency management can get quickly out > of hand. > > However, you obviously have to use bnd(tools) ... > > Kind regards, > > Peter Kriens > > > > On 29 jan. 2013, at 12:41, erwin dl wrote: > > > I often encounter situations where a certain class ClassA in a bundle A > depends on a class ClassB in a bundle B, and where ClassB is a subclass of > ClassC in a bundle C. > > > > So it is logical that bundle B has a dependency on bundle C. > > > > But to get the things compiled and working, I am forced in such a > situation to also add an explicit dependency of bundle A on bundle C. > > Even when not directly referring to the base-class in my ClassA... > > > > At least this is true in eclipse's PDE. > > But in internal discussions here, it seems to be perceived as an > inevitable fact, independent of eclipse or equinox implementation choices... > > > > I would prefer that the implementation decision of ClassB, to inherit > part of its stuff from ClassC, i.o. implementing it directly itself, would > be hidden for ClassA and bundle A. > > > > I.e. it is not a situation where a kind of API is provided in bundle C, > and where bundle A would better use the API, and where bundle B provides > implementations as services etc. > > It's a simple class-hierarchy set-up that exposes implementation > decisions and forces dependents to add a-priori "unnecessary" extra > dependencies... > > > > If someone has advice or ideas on this, I would be very interested to > hear/learn from them! > > > > Many thanks, > > erwin > > > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
