Isn't it just a case of updating the META-INF/MANIFEST.MF to being a plug-in osgi project (if it's not already?). It should look something like:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: My-plugin
Bundle-SymbolicName: com.mycompany.mypluginname
Bundle-Version: 1.0.0
Bundle-Vendor: MyCompany
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Service-Component:
Import-Package: org.apache.log4j;version="1.2.14" (, separated etc)
Export-Package: com.mycompany.mypluginname.myapipackage;version="1.0.0"
And then nicely omit the .internal package. The platform should do the rest.
By the way, you then use the Import-Package: in any dependent bundles, plugins etc, rather than depending on the jar/project (which is the old, sucky way which doesn't work - as you're finding).
This gives you massive de-coupling of your code dependencies. If you decide that your plugin code should belong in a different jar/bundle, you just move individual packages, and make the new bundle/plug-in export it. Since the client bundles just import the package from "the cloud" (cloud being the OSGi platform), you can move code a lot more freely.
Note: As mentioned in the comments, you don't need to be running your apps in OSGi to get this "benefit". Eclipse can compile it's code under OSGi package restrictions, and your build/server can run in "the unprotected world". e.g. the OSGi manifests don't enforce anything to 3rd parties (who wish to use .internal), but provide "notifications" and restrictions to those that want them.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…