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 18775 - Duplicate open files when navigating compile errors
Summary: Duplicate open files when navigating compile errors
Status: CLOSED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P4 blocker (vote)
Assignee: issues@utilities
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-12-18 12:15 UTC by Kevin Jones
Modified: 2003-07-01 15:31 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
ide.log file from when issue was happening (185.21 KB, text/plain)
2001-12-18 12:49 UTC, Kevin Jones
Details
ide.log file after starting with -J-Dorg.apache.tools.ant.module=0 (89.61 KB, text/plain)
2001-12-18 12:49 UTC, Kevin Jones
Details
Proposed fix. (1.71 KB, patch)
2001-12-19 11:01 UTC, _ lkramolis
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Jones 2001-12-18 12:15:19 UTC
I have a file open in the editor.
I compile (usin Ant) and I get compile errors
I navigate to the first error (F12) and a second copy of the file is opened in 
the editor.

NetBeans 3.3, W2K, JDK 1.4
Comment 1 Jesse Glick 2001-12-18 12:31:37 UTC
More details please:

- what filesystems do you have mounted (list of mount points)

- what relevant files are in those filesystems (relative names)

- full text of output (copy/paste from Output Window)

- run IDE with -J-Dorg.apache.tools.ant.module=0 and then attach
ide.log file for diagnosis

You probably have some kind of duplicate mount that makes it
impossible to tell from the error message exactly which file is
referred to. But without full details it is impossible to tell, or to
reproduce this.
Comment 2 Kevin Jones 2001-12-18 12:46:38 UTC
I have two CVS mounts
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\src and 
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\

in that order.

src contains all my .java files (in packages).
'Struts-MessageBoard' is the 'root' of the application. It has src, 
class, build and other subdirectories.

///// output window //////////////

prepare:
build:
Compiling 2 source files to C:\home\kevinj\Course\EJSP\lab\Struts-
MessageBoard\classes
com/develop/ejsp/struts/actions/ChangeGroupAction.java [7] 'class' 
or 'interface' expected
packag e com.develop.ejsp.struts.actions;
^

[other similar messages left out for clarity]

29 errors
build/build.xml [74] Compile failed, messages should have been 
provided.
BUILD FAILED
Total time: 0 seconds

BTW I always mount my directories like this and I'm don't think I've 
ever seen this before.

And of course, after re-starting the problems disappeared!
Comment 3 Kevin Jones 2001-12-18 12:49:05 UTC
Created attachment 3871 [details]
ide.log file from when issue was happening
Comment 4 Kevin Jones 2001-12-18 12:49:50 UTC
Created attachment 3872 [details]
ide.log file after starting with -J-Dorg.apache.tools.ant.module=0
Comment 5 Jesse Glick 2001-12-18 14:40:11 UTC
OK, here's my guess: you opened some source files from the mount point
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\ which you should
not do since this is not a classpath root. The Ant module then opened
the same sources from
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\src\ which is
correct since these *are* from the classpath root. According to your
log file, the Ant module found the source files correctly in the
classpath directory. When hyperlinking from a line in the Output
Window, where the filename as reported by the compiler could match
more than one mount point, it always gives preference first to
filesystems with the capability Use in Compiler turned on, and if that
does not resolve the ambiguity, the more specific mount point (longer
path prefix) is used.

You can find out which version of a file is opened in the Editor by
hovering the mouse over its tab and waiting for the tooltip. If in
fact you had originally opened the file from the wrong location, then
this is a user error so please mark the bug INVALID. Otherwise please
explain which version of the file you originally opened and which Ant
opened. Also the raw Ant output as given on the command line would be
helpful in determining why the path was misinterpreted. Also do you
use Jikes or Javac or something else?
Comment 6 Kevin Jones 2001-12-18 15:56:55 UTC
OK, thanks for the help.

I'm adding files to the 'project' from outside of NetBeans, i.e. I'm 
copying already existing files into the src directory (all package 
directories in place), and then opening the file by dbl-clicking on 
it. The first time I do this NB queries for the package. If I choose 
a package NB automatically mounts that path (even if it's already 
mounted as a CVS mount). If I close the file and unmount the 
directory, next time I dbl clk the file is loaded, but it is loaded 
from the 'wrong' mount point, i.e. from 
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\ not from
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\src

So this isn't an Ant bug, although I still regard it as a feature!

If I do a File..Open I get the write mount directory
Comment 7 Jesse Glick 2001-12-18 17:07:38 UTC
Aha. You forgot to mention the use of Open File. The primary bug seems
to be this:

"The first time I do this NB queries for the package. If I choose a
package NB automatically mounts that path (even if it's already
mounted as a CVS mount)."

I thought this was fixed long ago, but perhaps not, or perhaps
FileUtil.fromFile is malfunctioning with CVS mounts.

"If I close the file and unmount the directory, next time I dbl clk
the file is loaded, but it is loaded from the 'wrong' mount point,
i.e. from C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\ not from
C:\home\kevinj\Course\EJSP\lab\Struts-MessageBoard\src"

This is "as designed" for Open File, i.e. if there is an existing
mount which can open a file, it will use it. However for Java sources
that behavior is basically wrong. (It is also an Open File bug, not as
designed, if at this time you still had your src\ CVS mount.)

(I originally wrote Open File's "smart" package-driven mounting
behavior some years back and have been trying to convince
nbui@netbeans.org to delete Open File ever since, without success. It
causes more problems than it solves IMHO.)

Having opened the wrong version of a source, the Ant module is not
really at fault; it is then opening the correct version. I have
suggested that Java sources present in the wrong package be clearly
marked with some sort of warning in the icon, but this was never done.
(Once they were marked with the "parse error" badge but this confused
people since the sources were valid other than their position.)

Workaround for all this: make your CVS mounts properly (main dir and
src\), set Use in Compiler on the source dir, turn it *off* on the
main dir, always open Java sources from the source dir, and do not use
File | Open nor double-clicking in the Windows Explorer to open files;
open them from the Explorer.
Comment 8 _ lkramolis 2001-12-19 11:00:07 UTC
I find, where the problem is. Method FileUtil.fromFile returns array
of FileObjects - in order of mounted file systems, so if you have
first mounted main dir, this FileObject is used.

Because I am new to OpenFile module, I would like to ask Jesse to
review my patch before integration. Thanks.
Comment 9 _ lkramolis 2001-12-19 11:01:21 UTC
Created attachment 3886 [details]
Proposed fix.
Comment 10 Jesse Glick 2001-12-19 12:43:17 UTC
The patch to OpenFile looks right, I think. (Petr Zavadsky actually
knows more about the current code in this class, he has worked on it
more recently.)

It might also be desirable (though much less important) to also for
non-*.java files try to open the "best match": take the FileObject[]
and return the one with the shortest name (getPackageNameExt). This
would favor opening files from more specific inner mounts rather than
more general outer mounts.
Comment 11 _ lkramolis 2001-12-19 15:10:20 UTC
I agree, Jesse, with your suggestion to select the shortest name of
non-*.java files -- patch was enhanced.

[Fixed in release33 branch.]


Comment 12 Quality Engineering 2003-07-01 15:29:13 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 13 Quality Engineering 2003-07-01 15:31:49 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.