Hi Erwin, hi Toni, that is a well known problem in the PDE - there are several bug entries related to this issue in the eclipse bugzilla, e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=148844 or https://bugs.eclipse.org/bugs/show_bug.cgi?id=137710
>From my POV the underlying problem is that the PDE does not resolve project dependencies transitively (there has been a discussion about this topic, but I can't find the related issue anymore). Some years ago Chris Aniszczyk blogged about an approach to define "additional" dependencies in the PDE that may solve your problem: http://eclipsesource.com/blogs/2009/05/29/pdes-automated-management-of-dependencies/ Hope it helps! Regards, Gerd 2013/1/29 Toni Menzel <[email protected]> > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
