This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 43793

Summary: Absolute links created when referencing JAR inside project folder when not using VCS
Product: projects Reporter: Milan Kubec <mkubec>
Component: Generic InfrastructureAssignee: David Konecny <dkonecny>
Status: CLOSED FIXED    
Severity: blocker CC: issues, jglick
Priority: P4    
Version: 4.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 41535    

Description Milan Kubec 2004-05-25 11:49:51 UTC
I created a project and put all jars into folder
${project.dir}/lib, then I added all those jars to
compilation classpath but references are defined
in and are absolute.

The project would be better shareable if anything
refenced within project folder would be relative.
Comment 1 Jesse Glick 2004-05-25 12:16:00 UTC
Definitely the intention was that files collocated with the project
directory should be stored as relative paths. I guess this was forgotten.

Milan were you using VCS?
Comment 2 Milan Kubec 2004-05-25 12:35:26 UTC
Comment 3 Jesse Glick 2004-05-25 18:17:03 UTC
Ah, well nothing will produce relative links unless you are using VCS.
This is as designed. The problem is how to know that the links are
relative. If they are inside the project dir, probably we can safely
guess that they are. What if they are e.g. ../libs/foo.jar (libs in a
parent project)? Should they be stored as relative or absolute? What
about ../../libs/foo.jar? What about ~/proj1/ using a lib in ~/proj2/?
There is no easily definable policy. Using VCS ensures that everything
within the VCS root is considered part of one sharable file tree.

Leaving open but I am not sure what we could do differently that would
be consistent enough. Really this is about the behavior of any
CollocationQueryImplementation's we turn on in the IDE by default.

Note that the user can always manually move absolute filenames from to be relative filenames in if
they know that they should be shared.
Comment 4 Milan Kubec 2004-05-25 21:12:29 UTC
I see that policy for relative links can be complex, but why we cannot
leave it to user to decide which jar will be referenced by relative
link and which one by absolute. There might be a checkbox when
selecting a jar - '[] Relative link'. But anyway it won't be in D.

But I don't see the problem if user selects some jar inside project
dir, what's the problem here? It would allow to create easily
shareable projects for no price IMHO. I've downloaded couple of
projects from sourceforge and each of them contains lib folder with
all required jars inside project dir. I created a nb project of it,
created the same structure with lib under project folder, but ...
links are absolute which means that if I send the project to my
coleague it won't work. But the original project from works
well without setting anything. Why we cannot create selfcontained project?
I know that user can modify (I did it this way),
but not everybody will know how to "hack" project metadata.
Comment 5 David Konecny 2004-05-26 09:15:05 UTC
I plan to fix what subject complaints about because it bug for me -
"Absolute links created when referencing JAR inside project folder
when not using VCS". The rest is >promoD.
Comment 6 Jesse Glick 2004-05-26 16:29:01 UTC
"But I don't see the problem if user selects some jar inside project
dir, what's the problem here?" - none. The problem is where to stop.
If the JAR is really close to the project directory, should it be
relative? Sometimes, but maybe not. Only using VCS tells the IDE
explicitly what you want.

Re. providing a checkbox to set this - maybe, though I fear such a UI
would just distract and confuse more users than it would help.
Comment 7 Milan Kubec 2004-05-26 22:29:08 UTC
I mean only situation when jar is inside project e.g.:
MyProject/lib/mylib.jar or
in this case you don't need (at least I hope) to decide where to stop
you just reference the jar beginning with lib/ resp. myjars/

Or am I missing some basic point here?
Comment 8 Jesse Glick 2004-05-27 08:58:15 UTC
The consideration is just that it may be weird if the situation you
described works but this does not:

master/proj1/nbproject/ [etc.]
master/proj2/nbproject/ [etc.]

and you edit e.g. proj1 and ask to use x.jar. Probably you meant to
refer to "../libs/x.jar". Under the proposed change you will get
"/home/me/projects/master/libs/x.jar" as now. It might not be clear
why this doesn't work but it does work if the JAR is inside the
project directory.
Comment 9 Milan Kubec 2004-05-27 09:04:40 UTC
OK, I see your point.
Comment 10 David Konecny 2004-06-03 13:42:25 UTC
Fixed in:
new revision: 1.13; previous revision: 1.12
Comment 11 Jesse Glick 2004-06-03 22:26:52 UTC
Provisionally reopening this because I think the fix was wrong -
rather than putting this into ReferenceHelper, should be a general
CollocationQueryImplementation so it would work even in other code
using CQ.
Comment 12 David Konecny 2004-06-14 09:35:45 UTC
Improved in:
initial revision: 1.1
initial revision: 1.1
new revision: 1.15; previous revision: 1.14
Comment 13 Jesse Glick 2004-06-14 17:09:50 UTC
Better, though:

1. No particular reason for the new CQI to be in projects/projectapi -
does not use the project system at all. May as well be in
projects/queries (and named appropriately).

2. PCQ.aC probably ought to work based on File's rather than
FileObject's so that the behavior would be consistent whether or not
the files currently exist on disk.

3. Fine for PCQ.fR to return null, no need for an XXX comment.

4. Unit test would be nice. :-)
Comment 14 David Konecny 2004-06-15 12:25:21 UTC
Reopening for myself to implement Jesse's comments.
Comment 15 David Konecny 2004-09-06 12:57:23 UTC
Fixed in:

new revision: delete; previous revision: 1.1
new revision: delete; previous revision: 1.1
Checking in
new revision: 1.4; previous revision: 1.3
Checking in
initial revision: 1.1
Checking in
initial revision: 1.1
Comment 16 Milan Kubec 2004-09-07 13:29:08 UTC
Verified in custom 20040907.