Community
Participate
Working Groups
I created a simple plugin com.ex.log that has a 3rd party jar in it (a single Log class), and export the package. Then I create another plugin that depends com.ex.log. Both com.ex.log and the new plugin work when self hosted, and can see the Log class through content assist and CTRL+SHIFT+R. I deploy both plugins, start eclipse in a new workspace with -clean. Both plugins continue to work as expected. If I create a new plugin test.log in this workspace, I can add com.ex.log as a dependency. But test.log can't see the Log class, and it won't show up in CTRL+SHIFT+R even though it's been exported from com.ex.log. I can see any exported packages that are in the com.ex.log deployed plugin, just not exported packages that are in the com.ex.log plugin in the 3rd party jar. The com.ex.log plugin has this manifest (which is correct): Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Log Plug-in Bundle-SymbolicName: com.ex.log; singleton:=true Bundle-Version: 1.0.0 Bundle-Activator: com.ex.log.Activator Bundle-Vendor: EX Bundle-Localization: plugin Require-Bundle: org.eclipse.ui, org.eclipse.core.runtime Eclipse-LazyStart: true Bundle-ClassPath: lib/example_log.jar, . Export-Package: com.example.log PW
This is a long-standing limitation. Nested JARs are not supported by JDT(ie. cannot be put on the classpath nor can they be indexed). Moving to jdt/core to resolve as appropriate.
*** Bug 136004 has been marked as a duplicate of this bug. ***
*** Bug 136813 has been marked as a duplicate of this bug. ***
*** Bug 138355 has been marked as a duplicate of this bug. ***
Hi, I'm currently faced to the same problem : some jar file included (and exported) in a plugin are not accessible to JDT. This is hardware and OS independant as i've tested it on XP or MacOS both running Eclipse 3.2.1.
Frederic, is there a plan to do something on the JDT side here? I am not aware of any compiler out there that can handle nested JARs. Interestingly, there is an enhancement request in the PDE bucket (bug 111238) that would handle extraction of JARs for JDT. We have not assessed the risk/benefit ratio yet. Shipping plug-ins as nested JARs is not a recommmended format anyway.
(In reply to comment #6) > Shipping plug-ins as nested JARs is not a recommmended format anyway. Yes, but shipping expanded plug-ins is also not recommended. So if you want to package up a third-party jar whose licensing terms don't permit it to be unpacked and included with all the other classes, there is no right answer. Also, ISTR that when I tried unpacking a third-party jar I ran into other problems with PDE that made it difficult to export a class folder into the plug-in; the memory is vague now (it was two years ago) but I think it had to do with not being able to have a consistent runtime classpath between my dev and deployed environments, i.e. I needed to have both "lib" and "." on my runtime classpath even though in any particular environment only one was being used. We ended up resorting to checking in the source code for the third-party jar and letting it be compiled as if it were our own source, which was skirting the limits of the licensing terms of that jar. Bottom line: when plug-ins need to include both source code and third-party jars, there does not seem to be a clean or correct "best practice" that will support development, testing, and deployment.
Marking as enhancement as we would need to support nested jars.
*** Bug 197996 has been marked as a duplicate of this bug. ***
Why is this jar different than any other nested jar ? e.g. I have many plugins that have nested jars in it to have access to e.g. hibernate, log4j, etc.
(In reply to comment #10) > Why is this jar different than any other nested jar ? > > e.g. I have many plugins that have nested jars in it to have access to e.g. > hibernate, log4j, etc. > We simply don't have support to have a classpath entry point at a jar file inside another jar file. So we cannot resolve the classes inside the nested jar.
Isn't it a duplicate of bug 111238?
