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.
[dev-200409121800, JDK 1.5.0 RC] 1) Create *compilation* project dependency as follows: A -> B -> C 2) Create *runtime* dependency: A -> C 3) Close those projects and move them somewhere to break those dependencies. 4) Open project A and B 5) Resolve dependency for project B (missing C) Error: You have to resolve the same dependency (missing C) for project A again.
When broken link is resolved there is no information that just resolved missing project C is also on classpath of project A. All I have is a property name which user has to map to some project. The property name is generated from project's name so in most of the cases I could use it to identify project, but sometimes it can fail: if there are two projects with the same name etc. This could be changed to ENHANCEMENT, but IMO it is not worth the effort. Real devevelopment is usually under a VCS in which case projects will be referenced relatively. So the case described here should be quite rare. WONTFIX for now, but feel free to disagree.
Well, there might be some developers reasons why this cannot work, but I think that those reasons are not so interesting for the user. He just has to do the same action twice or maybe more times depending what all dependencies he has set, so please keep this issue opened as enhancement. <personal-note> I admit that real development should be in VCS, but there are users doing unreal :) development as well and we should treat them well too. </>
"Well, there might be some developers reasons why this cannot work, but I think that those reasons are not so interesting for the user." - sure, I just mentioned them here as technical evaluation of the problem. "I admit that real development should be in VCS, but there are users doing unreal" - sure, but why should we support them? Why this is P2 enhancement? Is it really that important feature? Maybe I just need to hear more usecases, but so far IMHO this is P4 future which never will get fixed because there is much more important things. Instead of fixing that I would recommend somebody who is using inter-project dependencies which are not under one VCS and want to share these projects with other users to update build.properties by hand (just once) to use relative paths. Then it would work out of the box.
Agree with David, this is not a priority at all.
Milan proposed a solution (on a NetCat thread) based on replacing absolute path common root with '../' Main project path: C:\Document[...]\projects\MainProject Library project path: C:\Document[...]\projects\LibProject Thus, Library project path in Main project dependencies: ../LibProject This could solve the problem. In my case I copy the whole projects folder to my notebook, from W_XP to Linux. And I'm not the only one, NetCAT have, at least, one more. 2 out of 60.
Do not want to automatically use relative paths for "sister" directories like this. Where would it end? If you have a project in /home/jglick/prj/myapp and a lib in /space/libs/saxon, is "../../../space/libs/saxon" a reasonable relative path? Don't think so. The current code (CollocationQuery) uses relative paths in two cases: 1. Both dirs are part of the same (configured) VCS checkout, meaning you probably meant to use that structure. 2. One dir is inside another, again meaning you probably meant to keep it all together. These cases should cover many of the common situations where a relative path is desired, and do so fairly safely. Otherwise, it is just too dangerous to make such guesses (IMHO). A future release could have a way for the user to adjust the IDE's guess in case it is wrong. Should probably not be part of the UI that initially creates the path, e.g. Add dialog from classpath customizer - too subtle a concept to thrown at a novice user, likely to cause confusion - but could be available in the UI somewhere after creating the path. (E.g. a separate "File Paths" tab in the properties dialog, perhaps?) We will not do this for 4.0. In 4.0, you are always free to make absolute paths relative, or relative paths absolute, by editing project.properties and private.properties - relative paths go in project.properties, absolute paths in private.properties.
OK ;D !! I already did it when Milan suggest it. Anyway, I was meaning COMMON ROOT, in that case you would never end up with such a path as ../../[...] (at most ../[...] or no replacement) and wouldn't be so dangerous.
But why only ../? What about ~/devel/projects/app vs. ~/devel/libs/somelib = ../../libs/somelib? There is no clear place to stop.
You're right, in case projects aren't sharing the same root, paths became messy, but the stop point isn't so blurred. Whereas your point is clear, changing paths seems dangerous. I agree. But the use case you were solving is not so rare. Depending on the amount of projects is much more easy copying a folder than entering each project in order to update sources. Afterall, notebooks not always have CVS available, nor share directory structure. And projects aren't composed only by CVS content ;D
Back to why I set this as P2 ENH: It's not about this particular usecase only IMHO, but about feature that works half way. You have two or three projects depending on the same one project, you resolve dependendcy and oops you resolve the same dependency again and ... once more. Not everything can work through VCS, I can easily send bunch of projects to my coleague (with exactly this chain of dependencies, it's not so uncommon - two users reported that on NetCAT) and he will fall into resolving one dependency twice or more times.
Well we should probably have some enhanced GUI for marking paths as relative in a future release.
RE: identifiyng where to stop with the ../..'s What if there were a property, that was used as the default location to create new projects. The user could set it however they wanted (C:\devel,~/proj, etc.) Couldn't this directory be treated like the $CVSROOT is now? if both projects are within this area, use relative pathnames? if not use absolute? (On the other hand, on the window to add dependcies, there could just be a check box to "use relative paths".) And while reading this issue I noticed that it's gotten a little side-tracked, The original issue seemed more to be about needing to repeat a UI action multiple times. Is there something that stops NB from saying "Oh, so that's where C lives... Does this info let me resolve dependencies for any other projects?" and automatically fix those too?
Re. having a property that would work like VCS root in terms of making paths relative beneath it - sure, possible. In fact, possible to implement as a completely separate module. (Plug in a CollocationQueryImplementation.) "Is there something that stops NB from saying "Oh, so that's where C lives... Does this info let me resolve dependencies for any other projects?" and automatically fix those too?" - yes (besides transient reasons such as the fact that this might require an API change); there is no unambiguous definition of project identity. A project is whatever you find in a project folder; the name is just for displaying to people. If A says it needs a project named "C" and B says it needs a project named "C" and you tell the IDE that for A, C lives in z:\stuff\c, it is not safe to make that link for B too; B might be referring to a completely unrelated project also named "C".
For the sake of illustration I wrote such a module and will attach both fully working NetBeans module jar and also zip file with sources and test. Can be used as example in developer's guide. Module description contains how to use it: in userdir in build.properties set a property "reference.points" to a directory (or directories; separated by : or ;) which is common root below which all references should be relative.
Created attachment 17649 [details] NB module jar
Created attachment 17650 [details] zip file with module sources
Jesse, I'm moving project infrastructure base freeform issues to you.
I don't follow the what the issue is about and why it's assigned to "projects/code" is this only about making sure the dependency reference on another project is a relative path or a path based on some variable?
Change of default owner.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss