Community
Participate
Working Groups
I am using 3.0 ibuild 20030924 and i suddenly notice that if i want to attach source to a jar and i see that i can only choose: Workspace or external things. But i miss variable. Because now i have more then one jar that doe have src jars outside the workspace so with hard paths like: c:\tomcat4.1.24\lib\catalina-src.jar If for example i would use a plugin of eclipse and i point directly with a jar with a variable: <ECLIPSE-HOME\plugin\org.eclipse.swt\swt.jar then the src must suddenly be a hard path!
The limitation is that you can't mix normal paths with variable paths: If your classpath entry is a variable classpath entry, you have to also do the source attachment as a variable path. If it's not a variable classpath entry, then also the source attachment path is a normal path. Sounds limiting I know, but that what's jdt.core currently offers. Do you want me to formard this a bug to jdt.core (don't be diappointed if the change it to 'LATER' or 'WONT FIX'...
Deferred post 3.0
Is this or anything like it being addressed in 3.1? Seems like a very common scenario that a project would have JARs checked in (and thus the Eclipse Project would reference them "locally" within the Project). However, currently (3.0.x) that means you have to hard code an absolute path in order to attach source to such JARs. Things are is simply broken in that scenario, since it is unlikely that every machine/developer will have 3rd-party library source in exactly the same location. I'm certainly not going to burden our CVS repository or project structure with 3rd-party source code. What is involved in getting this fixed?
Eric, if I understand your scenario correctly, you have a lib.jar in a project P (/P/lib.jar) and its source in an external location (eg. c:\sourcelibs\libsrc.zip). In this case, you can define 2 variables: - WORKSPACE that points at your workspace location (e.g. c:\eclipse\workspace) - SOURCE that points at your source directory (e.g. c:\sourcelibs) Then add WORKSPACE as a variable on your buildpath and extend it (see the Extend button) to point at your /P/lib.jar. Finally attach SOURCE and extend it to point at libsrc.zip. The classpath entry in the .classpath file should look like: <classpathentry sourcepath="SOURCE/libsrc.zip" kind="var" path="WORKSPACE/P/lib,jar"/>
Yes, Jerome, that will work (I think) but you have to admit it is an awkward workaround. I hope that 3.1 provides the ability to use variables for source paths so that such trickery is not required.
I'm not sure how we could define such a classpath entry. Right now it is either of kind 'lib' or 'var'. We would need a mixture of both kinds. The API JavaCore.newLibraryEntry(...) needs to be re-thought as well as the .classpath encoding.
I guess the "general public" does not understand why that limitation exists in the first place. It seems arbitrary, at least to those who are not intimate with the Eclipse source code and design. I humbly suggest that making the .classpath entries more flexible in this manner is a general improvment to the platform.
Reopening to consider (time permitting unless someone provides a patch)
I'm afraid users still have to use workaround described in comment 4 for 3.1... Defer post 3.1
Almost a year since last comment - 5 votes show there is interest in this. Why is there no attention to it?
Sorry we didn't have time/resources to do it for 3.2 but this will be considered for 3.3 (along with allowing more classpath flexibility).
I fully agree this this is very uncomfortable for users. I also had full pathes (even to a shared drive) in my .classpath because of this. Another "workaround" would be to create a "Source_Libraries" project in your workspace. Then copy all the source jars into this project. This project does not have to be in cvs. In the "source attachment" dialog you then coose "Workspace" and reference the source jar from inside the other project. For other developers this means that you provide them with the "Source_Libraries" project which can be seen as kind of variable. The .classpath entry will look like this afterwards: <classpathentry sourcepath="/Source_Libraries/libs/commons-logging-1.0.4-src.zip" kind="lib" path="lib/commons-logging-1.0.4.jar"/>
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
