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.
Maybe its a 'new cvs' issue. With NB4.1, when a project is created in a directory that parents are in cvs and dependencies to jars in the same cvs tree are established, the dependency was stored in project.properties in a relative way: file.reference.j3dcore.jar=../third-party/java3d/win32/lib/ext/j3dcore.jar Now, with NB5, the reference is stored in private/private.properties with absolute path: file.reference.j3dcore.jar=D:\\DRTS\\projects\\third-party\\java3d\\win32\\lib\\ext\\j3dcore.jar I think this is bad.
AFAIK the path is still also stored as relative in project.properties, right? So the problem is that there is a redundant absolute definition in your private.properties?
nope, the path is only stored absolute in private.properties. I attach the files. What I did validate the issue is to create a project with NB41 and NB5 in sibling directories under a cvs and compared the resulting files. NB41 was fine.
Created attachment 24901 [details] project.properties
Created attachment 24902 [details] private.properties
P2 if reproducible.
I've created an project under the CVS root and library also under the CVS root. CVSRoot --Project --lib.jar Then I've added the lib.jar into the Project's classpath. The private.properties contains: file.reference.lib.jar=/tmp/01/CVSTest/lib.jar The public.properties contains: file.reference.lib.jar=../lib.jar javac.classpath=\ ${file.reference.lib.jar} The content of these files is right. The property file.reference.lib.jar can be removed from the project.properties by another CVS user which do not have lib.jar checked out and resolves it as a broken reference to other location and commits such a change.
I'm sorry ... if its not a NB-bug ... at least there is a difference! I attached to zips with projects created with NB41 and NB5 below the same CVS tree side by side and created a dependency to file.reference.jsr173_1.0_ri.jar. The 4.1 project contains the reference ONLY in project.properties and not in private.properties. The 5.0 project does ONLY have an entry in private.properties. NB5 uses the new CVS, NB41 the old of course.
Created attachment 25075 [details] NB41 project
Created attachment 25076 [details] nb5 project
I did more tests and under some conditions I managed to get an entry in project.properties as well. Is it possible that it depends on the length of the path, or the number of directories involved? Placing a project on some level of directory, I can achieve a file.reference.j3dcore.jar=../third-party/java3d/win32/lib/ext/j3dcore.jar Pulling the project one level up (would be ../projects/third-party/java3d/win32/lib/ext/j3dcore.jar), there no longer is an entry in project.properties. 2. Test: I could get a file.reference.j3dcore.jar=../../third-party/java3d/win32/lib/ext/j3dcore.jar But, placing my project 1 level deeper (should result in ../../../third-party/java3d/win32/lib/ext/j3dcore.jar), again, the entry only shows up in private.properties. Does this make sense in any way??
Another test I did: I installed the 'old' cvs from the update center. The project setup now works again as it did with NB41. Given the fine-grained, nested project layout of the www.flyingguns.com project, the current NB5 does not allow to setup any projects that can be checked into cvs without doing the necessary adjustments (carry properties from private.properties to project.properties) by hand.
It works fine on the UNIX (Linux), it seems to be a Windows specific issue. I will try to reproduce it on Windows.
Finally I was able to reproduce this on Windows. The thing is that File.listRoots() returns on my computer {File("C:\\"), File("D:\\")}, but if you ask File ("C:\\").getParentFile () you get sometimes null, which is the right value and sometimes you get something like File ("This Computer") which is not correct. In the case when "This Computer" is returned the AlwaysRelativeCollocationQuery returns false even when it should be true. I have a fix, but it makes the CollocationQuery a bit slower. The second reason of this problem is that the new CVS does not provide CollocationQuery at all, no one cares that the files are in the same CVS.
The File("C:\").getParent() returns File("This Computer") only in the case when the file comes from the JFileChooser. The right fix is to add an assert for the file not to be the file from JFileChooser.
Re. "the new CVS does not provide CollocationQuery at all, no one cares that the files are in the same CVS" - we could always resurrect http://www.netbeans.org/source/browse/projects/queries/src/org/netbeans/modules/queries/Attic/SampleCVSCollocationQueryImpl.java?rev=1.3&hideattic=1&content-type=text/vnd.viewcvs-markup into the cvslite module.
Checking in src/org/netbeans/modules/queries/AlwaysRelativeCollocationQuery.java; /cvs/projects/queries/src/org/netbeans/modules/queries/AlwaysRelativeCollocationQuery.java,v <-- AlwaysRelativeCollocationQuery.java new revision: 1.2; previous revision: 1.1 done