Bug 43793

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?

No VCS.

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
private.properties to be relative filenames in project.properties if
they know that they should be shared.

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 sf.net works
well without setting anything. Why we cannot create selfcontained project?
I know that user can modify private.properties (I did it this way),
but not everybody will know how to "hack" project metadata.

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.

"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.

I mean only situation when jar is inside project e.g.:
MyProject/lib/mylib.jar or
MyProject/myjars/for/this/project/lib/mylib.jar
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?

The consideration is just that it may be weird if the situation you
described works but this does not:

master/
master/libs/
master/libs/x.jar
master/proj1/
master/proj1/nbproject/ [etc.]
master/proj2/
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.

OK, I see your point.

Fixed in:
src/org/netbeans/spi/project/support/ant/ReferenceHelper.java;
new revision: 1.13; previous revision: 1.12

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.

Improved in:
projects/projectapi/src/META-INF/services/org.netbeans.spi.queries.CollocationQueryImplementation;
initial revision: 1.1
projects/projectapi/src/org/netbeans/modules/projectapi/ProjectCollocationQuery.java;
initial revision: 1.1
ant/project/src/org/netbeans/spi/project/support/ant/ReferenceHelper.java;
new revision: 1.15; previous revision: 1.14

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. :-)

Reopening for myself to implement Jesse's comments.

Fixed in:

Removing
projectapi/src/META-INF/services/org.netbeans.spi.queries.CollocationQueryImplementation;
new revision: delete; previous revision: 1.1
Removing
projectapi/src/org/netbeans/modules/projectapi/ProjectCollocationQuery.java;
new revision: delete; previous revision: 1.1
Checking in
queries/src/META-INF/services/org.netbeans.spi.queries.CollocationQueryImplementation;
new revision: 1.4; previous revision: 1.3
Checking in
queries/src/org/netbeans/modules/queries/ParentChildCollocationQuery.java;
initial revision: 1.1
Checking in
queries/test/unit/src/org/netbeans/modules/queries/ParentChildCollocationQueryTest.java;
initial revision: 1.1

Verified in custom 20040907.