When you say Eclipse I assume you mean the IDE. I beleive this is a compiler visibility issue. The compiler is not fully trained in the ways of OSGi. They approximate it by access rules which hide packages but issues like this arise.
Another similar issue comes up with inner classes and inheritance across bundle boundaries. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=152568 BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Niclas Hedhman <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 02/21/2007 10:24 PM Please respond to OSGi Developer Mail List <[email protected]> To OSGi Developer Mail List <[email protected]> cc Subject [osgi-dev] Access to Non-exported methods... Hi, since Eclipse is complaining if I do; -o-o- Bundle A -o-o- package internal; public abstract class NonExportedAbstractBase { protected void doSomething(){}; } package exported; public abstract class ExportedAbstract extends NonExportedAbstractBase { } -o-o- Bundle B -o-o- public class InOtherBundle extends ExportedAbstract { public void someOther() { doSomething(); } } Eclipse[1] will complain and say that "doSomething()" is not an available method. If I add; protected void doSomething() { super.doSomething(); } in ExportedAbstract class, Eclipse no longer complains. Is there anything in the specs that implies that doSomething() is not exposed through the exported subclass?? Cheers Niclas [1] Still in Eclipse 3.3M? _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
