| [cross-project-issues-dev] Jars in jars is good citicenship? |
I think this creates problems for downstream projects that have dependencies on these jars when the plug-ins themselves contains other jars. The eclipse runtime can handle this but the compiler can't. Here's a use case (using a component that is not part of Ganymede, but anyway) that highlights this.
I'm developing the Subclipse plug-in for Buckminster. It is dependent on the org.tigris.subversion.subclipse.core. This plug-in is only available as a jar'ed plug-in that in turn contains other jars and this is the cause for some headache.
I have it installed in my IDE (or in my target platform) but I still get compilation errors. The remedy is to import the plugin into my workspace. When I do that, and the compiler errors disappear. Unfortunately, now I break the self-hosting instead. So I need to handcraft the bundle selection in my launcher and specify that this bundle must be picked from the target platform rather then from my workspace. Now everything works fine.
I've been told that since all jars that are needed are available as OSGi bundles in Orbit, this problem doesn't exist. No jars in jars construct is ever needed. I think there are exceptions to that rule. A bundle that provides Ant tasks for instance, needs to keep them separate from what's seen by the bundle classloader and hence, must use the jars in jars mechanism. Perhaps there are other cases that I'm not aware of.
My point is, perhaps "Should Do item #1" should be changed to "Projects that doesn't produce plug-ins that themselves contain jars should have jar'ed plug-ins because this is good Eclipse citizenship"?
Regards, Thomas Hallgren