Bugzilla – Full Text Bug Listing
| Summary: | [build path] Internal and external libraries cannot be distinguished on Solaris and Linux | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mirko Raner <mirko> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | gm.romanato, philippe_mulet, ville |
| Version: | 3.4.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Sun | ||
| OS: | Solaris | ||
| Whiteboard: | stalebug | ||
I agree with Mirko, if you get a request support from a colleague because an application is not working in his workstation, it will take you ages to figure out that the root cause is that the colleague has two different versions of the same JAR, one in the workspace and one external in the file system, and that the JDT is not picking the external JAR that the user correctly selected when setting up the classpath.. I'd also like this (very old!) bug fixed, although I agree that this should seldom cause problems. This can be solved in a backwards compatible way: just add a new attribute for the type of the path. So instead of the plain ambiguous <classpathentry kind="lib" path="/libs/a.jar" /> we would have <classpathentry kind="lib" path="/libs/a.jar" path-type="external" /> (alternative: path-type="filesystem") for a filesystem path and <classpathentry kind="lib" path="/libs/a.jar" path-type="workspace" /> for a path relative to the Eclipse workspace. Old Eclipse versions could keep on guessing the path type, but newer versions would read the attribute. Simple, right? So my proposal would reflect the idea and vocabulary of the GUI: it talks about external and workspace jars, so the .classpath file should also. Which reminds me of another related (minor) problem in the classpath GUI: why does it make a distinction between class folders and jars? They are both just items in the classpath, and there is no difference in syntax nor semantics. Of course if the file dialog user experience suffers from removing this difference, it might be necessary to make this distinction. Anyway, not a big problem. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build ID: M20080911-1700 Steps To Reproduce: 1. In the root of the file system ("/"), create a directory called "test" and copy a random JAR file to the directory 2. In the Eclipse workspace, create a Java project also called "test", and copy the same random JAR file into that project 3. Create another Java project, open the project's Java Build Path properties page, click "Add External JARs...", and add the JAR file from the "/test" directory that you created in step 1; the JAR will appear with a "/test" location path in the dialog 4. Open the .classpath file of the newly created project; the JAR will appear as <classpathentry kind="lib" path="/test/some.jar"/> 5. Create a third Java project, and this time add the JAR file from the "test" project that is located in the workspace; the JAR will appear with a "test" location path (without leading slash) in the dialog 6. Open the .classpath file of this third project; the JAR will have an entry identical to the one observed in step 4: <classpathentry kind="lib" path="/test/some.jar"/> 7. Effectively, the two projects both point to the JAR file in the workspace; if you open the Java Build Path properties of the project that was supposed to point to the JAR in the file system, you will notice that the JAR is now also listed with the location "test" (without leading slash), which indicates that it points to a resource in the workspace More information: JDT cannot really distinguish between internal and external libraries. On Windows, the current implementation is pretty safe because file system paths always have a device identifier (C:, D:, ...) which makes them distinguishable from absolute paths in the workspace. On operating systems like Solaris or Linux, which don't use device names in paths, it is possible to run into ambiguities as described above. The current distinction between internal and external resources is based on a mere heuristic implemented in JavaModel.getTarget(...) - see bug 24243, or bug 82750 comment 10. Whereas it is probably rare that a confusion occurs in practice, if it does happen it is very hard to debug and likely to waste a significant amount of engineering time. An essential distinction such as internal versus external libraries should be unambiguous in all cases and should not rely on heuristics. To fix this issue, future versions of JDT could, for example, introduce a new attribute that specifies whether an entry points to an internal or external resource.