Bug 48922

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