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.

Bug 48922 - [40cat] Dependency on the same project must be resolved twice
Summary: [40cat] Dependency on the same project must be resolved twice
Alias: None
Product: projects
Classification: Unclassified
Component: Ant Project (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Stupka
Depends on:
Blocks: 41535
  Show dependency tree
Reported: 2004-09-13 11:04 UTC by Milan Kubec
Modified: 2016-07-07 08:37 UTC (History)
1 user (show)

See Also:
Exception Reporter:

NB module jar (5.71 KB, application/octet-stream)
2004-09-15 13:44 UTC, David Konecny
zip file with module sources (10.35 KB, application/octet-stream)
2004-09-15 13:45 UTC, David Konecny

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kubec 2004-09-13 11:04:05 UTC
[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.
Comment 1 David Konecny 2004-09-13 14:56:49 UTC
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.
Comment 2 Milan Kubec 2004-09-13 15:18:50 UTC
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
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.
Comment 3 David Konecny 2004-09-13 15:37:07 UTC
"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 by
hand (just once) to use relative paths. Then it would work out of the box.
Comment 4 Jesse Glick 2004-09-13 15:54:00 UTC
Agree with David, this is not a priority at all.
Comment 5 llturro 2004-09-13 17:49:15 UTC
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.
Comment 6 Jesse Glick 2004-09-13 18:56:45 UTC
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 and - relative paths go in, absolute
paths in
Comment 7 llturro 2004-09-13 19:19:19 UTC
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
Comment 8 Jesse Glick 2004-09-13 20:36:23 UTC
But why only ../? What about ~/devel/projects/app vs.
~/devel/libs/somelib = ../../libs/somelib? There is no clear place to
Comment 9 llturro 2004-09-14 07:18:48 UTC
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
Comment 10 Milan Kubec 2004-09-14 08:35:19 UTC
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.
Comment 11 Jesse Glick 2004-09-14 18:43:43 UTC
Well we should probably have some enhanced GUI for marking paths as
relative in a future release.
Comment 12 kjmcdonald 2004-09-14 20:11:07 UTC
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?

Comment 13 Jesse Glick 2004-09-14 21:13:48 UTC
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

"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".
Comment 14 David Konecny 2004-09-15 13:43:06 UTC
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 set a property "reference.points" to a directory (or
directories; separated by : or ;) which is common root below which all
references should be relative.
Comment 15 David Konecny 2004-09-15 13:44:25 UTC
Created attachment 17649 [details]
NB module jar
Comment 16 David Konecny 2004-09-15 13:45:10 UTC
Created attachment 17650 [details]
zip file with module sources
Comment 17 David Konecny 2005-01-24 13:43:32 UTC
Jesse, I'm moving project infrastructure  base freeform issues to you.
Comment 18 Milos Kleint 2008-10-14 13:05:59 UTC
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
Comment 19 Antonin Nebuzelsky 2010-03-29 14:09:58 UTC
Change of default owner.
Comment 20 Martin Balin 2016-07-07 08:37:10 UTC
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