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.
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 private.properties and are absolute. The project would be better shareable if anything refenced within project folder would be relative.
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.