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 - Resolving broken file references too painful
Summary: Resolving broken file references too painful
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P4 blocker (vote)
Assignee: David Konecny
URL: http://projects.netbeans.org/nonav/bu...
Keywords: UI
Depends on:
Blocks: 41535
  Show dependency tree
 
Reported: 2004-08-31 07:17 UTC by tboerkel
Modified: 2005-01-18 17:21 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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/private.properties) 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, private.properties 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 project.properties 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 project.properties.
Comment 3 tboerkel 2004-09-01 08:23:41 UTC
Correction:
It seems like that project was created with an older dev version. In a
newly created project, there are no absolute paths in private.properties.
Unfortunately, there is still one entry in private.properties, that
prevents sharing that file:
user.properties.file=C:\\Documents and
Settings\\tb\\.netbeans\\4.0beta1\\build.properties

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
Reevaluate.
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:
src/org/netbeans/modules/java/project/BrokenReferencesCustomizer.java;
new revision: 1.9; previous revision: 1.8
src/org/netbeans/modules/java/project/BrokenReferencesModel.java;
new revision: 1.15; previous revision: 1.14