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 48210

Summary: Resolving broken file references too painful
Product: java Reporter: tboerkel <tboerkel>
Component: ProjectAssignee: David Konecny <dkonecny>
Severity: blocker CC: dkonecny, jrojcek
Priority: P4 Keywords: UI
Version: 4.x   
Hardware: PC   
OS: Windows ME/2000   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 41535    

Description tboerkel 2004-08-31 07:17:57 UTC
Fixing broken file references (for example missing
JAR files for compilation) is too painful, if it's
more than a few.
At least the "Resolve Reference Problems" dialog
should remember the last used path.
Better would be to optionally allow multi-select
in the resolve dialog and the file requester, so
one could resolve everything in one step, if the
missing files are in the same directory.
Or allow to copy the path to all missing references.

As far as I can see, this is the only problem when
sharing projects between developers. This
(private/ seems to be the only
place where paths are hardcoded. Every other
project xml or properties file could be shared
(put under source control). So, when a new
developer joins the project, he can just get
everything from source control and then fix the
broken file references and so that should be
easier than it is now.
Comment 1 Jesse Glick 2004-08-31 14:07:55 UTC
Passing to Jano to consider what future improvements we could make.

Yes, is the only file that should be affected,
since this is what you do not check out but must define for yourself
acc. to your own disk layout.

Note that if your libraries are kept inside your project (or in the
same VCS working area) the IDE will automatically use relative paths
in which you can check in. The Broken References
dialog only appears if you have external file references that cannot
be shared.
Comment 2 tboerkel 2004-08-31 14:58:35 UTC
Actually, those JAR files are in a sub directory of the project, but
NB still made absolute references in
Comment 3 tboerkel 2004-09-01 08:23:41 UTC
It seems like that project was created with an older dev version. In a
newly created project, there are no absolute paths in
Unfortunately, there is still one entry in, that
prevents sharing that file:\\Documents and

Comment 4 jrojcek 2004-12-08 17:16:25 UTC
Snip from the spec in the URL field:
If the user resolves a reference for one JAR file the IDE scans the folder this JAR file resides 
in and checks whether other missing JAR files don't reside in the same folder. This way the 
user can resolve multiple broken JAR file references at once.
Comment 5 David Konecny 2004-12-09 08:29:53 UTC
Comment 6 David Konecny 2005-01-18 17:21:21 UTC
Jano, fixed according to UI spec with one difference: Resolve button
is always enabled so that you can alter resolved items. It is needed
especially for auto resolved items. Please update your spec.

Fixed in:
new revision: 1.9; previous revision: 1.8
new revision: 1.15; previous revision: 1.14