Comment 1 Martin Aeschlimann 2005-01-03 05:52:29 EST

jdt.core currently only supports the usage of variables in classpath variable
entries

Comment 2 Jerome Lanneluc 2005-01-04 06:21:49 EST

Martin, MG, I don't understand this bug report. In 3.1 M4 you can edit the
source attachment of a library based on a classpath variable in the Java Build
Path dialog. Can you clarify what is missing ?

Comment 3 Martin Aeschlimann 2005-01-04 06:45:34 EST

I understood the request that for a variable class path entry they don't want
the source attachments to be restricted to 'paths with variables' (say just a
normal path like 'c:\xy\x.jar')

I don't think we should do that, the point of variable entries is to not contain
any platform specific paths, also not for the source attachments.

Comment 4 MG 2005-01-04 22:48:21 EST

Yeah Martin is interpreting my request properly.  

I don't think the source should always be constrained to exist in the same place
or even relative to the same place that the installed _variable_ dependant jar
exists.  

I can still do what I want in the current version I just can't use the GUI to do
it - meaning I can take a library which is located with a variable and then edit
the .classpath file to have a sourcepath that does not include and is not
relative to that variable.

Comment 5 Martin Aeschlimann 2005-01-05 02:53:04 EST

I'm surprised that editing the .classpath file would work. Is this a new
jdt.core feature? How is a variable path distinguished from a non-variable path?

Comment 6 Jerome Lanneluc 2005-01-05 04:58:03 EST

Martin I don't remember we ever had the restriction that for a variable lib
entry, the source attachment had to be a variable as well.

Moving to JDT UI as there is no restriction in JDT Core.

Comment 7 Martin Aeschlimann 2005-01-05 05:21:19 EST

It's in fact specified in IClasspathEntry.getSourceAttachmentPath():

For variable classpath entries, the 
* result path (if present) has an analogous form and meaning as the 
* variable path, namely the first segment is the name of a classpath variable.

That's how I remember it and I think it makes sense as you can't distinguish a
variable path from a normal path and otherwise thing get really messy
(especially in the UI where we would end up with another 3 buttons (workspace
path, ext. file path, ext. folder path)
Variable entries have been designed to be shareable by not containing local file
system paths, so having a platform specific path as source attachment is not
such a good idea.

Comment 8 Jerome Lanneluc 2007-06-19 10:37:01 EDT

Martin is right, we cannot change this as this is clearly spec'ed.
No action planned.