Community
Participate
Working Groups
Hi, let me quote some text from a .classpath-file in a project created with Eclipse 3.2.1: <classpathentry kind="lib" path="lib/jogl-1.0.0.jar" sourcepath="lib/jogl-1.0.0-src.zip"> <attributes> <attribute name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" value="SWT-Test/lib/natives/jogl-1.0.0"/> </attributes> </classpathentry> As you can see, "path" and "sourcepath" are relative to the project-root. The projectroot is /path/to/workspace/SWT-Test. But the value of the additional attribute CLASSPATH_ATTR_LIBRARY_PATH_ENTRY is stored relatively to the workspace-root. My personal favourite of solving this inconsequence, is to store absolute paths only, but by using variables like ${project_loc}. Than all hassle of interpretating relative paths will be gone.
Addition: I am complaining, because projects can be stored in different folders when shared with CVS between several people/computers. Maybe, the folder "SWT-Test" is called "SWT-Test2" on another computer. Who knows? BTW: I changed by .classpath-file to use the variable ${project_loc}, and it seems to work! So this maybe just a UI problem. The UI should generate paths using variables like ${project_loc}, if possible.
(In reply to comment #1) > BTW: I changed by .classpath-file to use the variable ${project_loc}, and it > seems to work! So this maybe just a UI problem. The UI should generate paths > using variables like ${project_loc}, if possible. I was wrong. The variable ${project_loc} is sensible to the current selection within the package-explorer which is not what i intended.
The CLASSPATH_ATTR_LIBRARY_PATH_ENTRY attribute is used and stored by JDT/UI...
by JDT/debug...
Moving back to JUI. Although JDT launching defines the attribute, all instances of the attribute are created by JUI (see NativeLibAttributeConfiguration). We have an API for creating and decoding the attributes in JavaRuntime: public static String[] getLibraryPaths(IClasspathAttribute attribute) public static IClasspathAttribute newLibraryPathsAttribute(String[] paths) However, when creating the paths, we do not have a project context in order to tell if the attribute should be made project relative, or workspace relative. JUI may have this information, since they have a project context for the build path page. JUI could use ${project_loc} in this case to resolve to the project in which the entry is being used. However, for references in other projects, a workspace relative path would need to be used.
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.
