Quick answer to parts of your question: - Prefer composition over inheritance. Just don't build on inheritance and your developer life, not just the OSGi one, will be better ;) - Avoid Bundle dependencies. If you encounter a situation where you have the abstract class and the final one in same package you should carry it around in one bundle. Otherwise just make the abstract one explicit by giving it a separate package. (avoid split package)
You learn this quickly by avoiding PDE. Toni *Toni Menzel | Founder Rebaze GmbH* [email protected] | +49 171 65 202 84 http:// <https://mail.google.com/mail/u/0/goog_1770677242>www.rebaze.com | twitter @rebazeio <https://twitter.com/rebazeio> | LinkedIn Profile<http://www.linkedin.com/company/2553599> *Rebaze Pilot: *The free one day onsite consulting opportunity. We will capture your potential. *Rebaze Pass: *A unique subscription service for key technologies: OSGi, Maven, Chef, Jenkins. *Rebaze Onsite: *Our way to improving your development team on site. On Tue, Jan 29, 2013 at 12:41 PM, erwin dl <[email protected]> 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
