Summary: | [classpath] Content Assist not working for plugin dependency | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Paul Webster <pwebster> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | david, eclipse, ed, fraenkel, frederic_fusier, jacek.pospychala, jerome_lanneluc, jgarms, manderse, nicolas.jouanin, peter, philippe_mulet, wassim.melhem |
Version: | 3.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: |
Description
Paul Webster
2006-04-05 09:46:31 EDT
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? |