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 51955 - [40cat] Compile single is deactivated under specific circumstances
Summary: [40cat] Compile single is deactivated under specific circumstances
Status: CLOSED FIXED
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscore (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: RELNOTE
Depends on:
Blocks:
 
Reported: 2004-11-30 22:02 UTC by pasek
Modified: 2006-03-24 10:10 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Description of what is happening when a file on Versioning tab is selected. (5.68 KB, text/plain)
2004-12-07 15:29 UTC, Martin Entlicher
Details
Problems that occured after this fix. (3.79 KB, text/plain)
2004-12-08 14:36 UTC, Martin Entlicher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pasek 2004-11-30 22:02:23 UTC
[ BUILD # : RC1 ]
[ JDK VERSION : J2SE 1.5.0 ]

The context menu entries and F9 for single compile
of classes is deactivated under specific
circumstances and only reappear after IDE restart.

The following repro case works for me:

Project:
- simple Java library, the classes are stored
inside CVS.
- I start Netbeans und can single compile every
class with F9 or the context menu.
- My CVS server is down, so I cannot execute CVS
commands on the files!
- After I've performed a "Show versions" for a
single class (which failed), I can not compile
single classes anymore.
Comment 1 Milan Kubec 2004-12-01 08:49:41 UTC
Not sure what is the right component, reassigning to java/project for
eval.
Comment 2 Jesse Glick 2004-12-01 17:28:58 UTC
Milan please check for reproducibility with more precise steps.
Comment 3 Milan Kubec 2004-12-02 12:36:10 UTC
Easily reproducible. I just created CVS connection and didn't logged
in then I created Java Library in that CVS root. Any connection to CVS
failed since I wasn't logged it. Then I just opened pop-up menu for
java file and actions "Compile File", "Run File" and "Debug File" are
disabled. Reproducible on trunk too.
Comment 4 Jesse Glick 2004-12-02 17:43:07 UTC
I cannot reproduce on Linux w/ 041201.

1. cd /tmp; cvs co applet

2. Replace :pserver:jglick@cvs.netbeans.org:/cvs with
:pserver:bob@cvs.netbeans.org:/cvs in /tmp/applet/CVS/Root and
/tmp/applet/www/CVS/Root to simulate an unavailable login.

3. Versioning Manager, add CVS working dir in /tmp/applet. Use
command-line CVS client. Set Offline Mode (do not try to log in).

4. Create new Java Application in /tmp/applet/JavaApplication26.

5. Go to Projects tab and right-click "Main.java [Local]". Compile
File, Run File, and Debug File are enabled as expected.
Comment 5 pasek 2004-12-02 21:28:45 UTC
I think you missed the important step. Try a "Show versions" or
"Refresh" on that file. After that the context menu entries should be
disabled.
But I think this CVS case is not the only one. I also had the problem
being online and logged in CVS.
Comment 6 Milan Kubec 2004-12-02 21:47:22 UTC
I think that there must happen some unsuccessful communication with
CVS server. I didn't stress out that I didn't use offline mode, it
means that there were some communication with CVS that actually
failed. And that was maybe the reason. I will try that on linux too.
Comment 7 Jiri Kovalsky 2004-12-02 23:36:42 UTC
I have also reproduced it. Here is what I did:

1. Opened "JavaApplication1" project from D:\Tests\CVS\Work2
2. Registered D:\Tests\CVS\Work2 as :local: CVS in "Versioning Manager".
3. I saw "JavaApplication1|Source Packages|javaapplication1|Main.java
[Local]" since the project was not imported into repository yet.
4. The popup menu was enabled as expected.
5. I invoked "CVS|Show Versions" on "Main.java [Local]" and returned
to "Projects" view.
6. Now the menu items were disabled.
Comment 8 Jan Chalupa 2004-12-03 10:46:36 UTC
This is really strange and seems to be related to VCS support. Martin
please evaluate. Re-assign if the root cause is somewhere else.
Comment 9 Milan Kubec 2004-12-03 10:50:51 UTC
Reproducible for me even when I set offline CVS mode.
Comment 10 Milan Kubec 2004-12-03 11:01:10 UTC
I managed to reproduce the problem on Solaris too.

What I did:
1) Created CVS "mount" with empty working dir; I didn't logged in -
provided no passwd
2) Created Java Library project in that working directory
3) Created package and Java Class and Main Class
Compile File, Debug File and Run File was enabled
4) Went to Versioning window and invoked Show Versions
Compile File, Debug File and Run File was disabled in Project window!
Comment 11 Milan Kubec 2004-12-03 11:09:55 UTC
Reproducible on 4.0 Beta2 too.
Comment 12 Milan Kubec 2004-12-03 11:31:29 UTC
Reproducible on my linux too.
Comment 13 Martin Entlicher 2004-12-03 15:20:01 UTC
It looks that there is something wrong with Versioning Explorer. It's
irrelevant whether you have good CVS connection or not, you even do
not have to run any VCS command. Just expand the Versioning explorer
to the test file and select it. As soon as you click on it, the
Projects tab is collapsed and the compile action is disabled.
Therefore the Versioning Explorer does probably something wrong there...
Comment 14 Martin Entlicher 2004-12-07 15:29:15 UTC
Created attachment 19178 [details]
Description of what is happening when a file on Versioning tab is selected.
Comment 15 Martin Entlicher 2004-12-07 15:32:43 UTC
It was found, that the same project is opened twice! Once the user
opens a project in Projects, it acts upon FileObjects from
MasterFileSystem. As soon as a file is selected in VersioningExplorer
(whose nodes contains FileObjects comming from VCS FileSystem), the
same project is opened again with the root from VCS FS. See the
attachment.
That second project is then mistakenly used also on Projects tab.
Seems like an issue in the projects system.
Comment 16 David Konecny 2004-12-07 16:55:51 UTC
Interesting. LookupSensitiveAction checks selected node and
ActionsUtil.getProjectsFromLookup creates new project because
DataObject in node's lookup is based on FO from VCS FS which is
AbstractFO and not MasterFO.
Comment 17 Martin Entlicher 2004-12-07 17:08:40 UTC
Perhaps this can be "fixed" in Versioning explorer also, by exposing
only FileObjects from MasterFS.

But is the current behavior O.K. from the projects point of view ??
Comment 18 Martin Entlicher 2004-12-07 18:55:27 UTC
"Fixed" in Versioning view. FileObjects from VCS filesystem are not
exposed, therefore the second instance of the project is not created:

/cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FileNode.java,v
 <--  FileNode.java
new revision: 1.10; previous revision: 1.9

/cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FileSystemNode.java,v
 <--  FileSystemNode.java
new revision: 1.5; previous revision: 1.4

/cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FolderChildren.java,v
 <--  FolderChildren.java
new revision: 1.7; previous revision: 1.6

/cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FolderNode.java,v
 <--  FolderNode.java
new revision: 1.11; previous revision: 1.10
Comment 19 Martin Entlicher 2004-12-07 18:55:55 UTC
FIXED.
Comment 20 Martin Entlicher 2004-12-08 14:35:31 UTC
The fix is not complete, actions on revisions do not work and
occasionally NPE is thrown when unmounting VCS filesystem from
Versioning Manager. Exceptions are going to be attached...
Comment 21 Martin Entlicher 2004-12-08 14:36:16 UTC
Created attachment 19211 [details]
Problems that occured after this fix.
Comment 22 Martin Entlicher 2004-12-08 15:48:24 UTC
More reliable fix is in:

/cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FileSystemNode.java,v
 <--  FileSystemNode.java
new revision: 1.6; previous revision: 1.5

/cvs/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FolderNode.java,v
 <--  FolderNode.java
new revision: 1.12; previous revision: 1.11

Both Versioning Explorer and Compile action seems to work O.K. now.
Comment 23 pasek 2004-12-08 20:27:42 UTC
Will target milestone still be 4.1 or will it be fixed in 4.0??
Comment 24 Milan Kubec 2004-12-09 09:02:24 UTC
Martin, please provide workaround for 4.0 (if there is any), since I
doubt we can put it into 4.0 now.
Comment 25 Martin Entlicher 2004-12-09 10:19:36 UTC
There is no workaround other than a restart of NetBeans.
Comment 26 David Konecny 2004-12-09 12:09:06 UTC
You mean restart of NB and not using Versioning Explorer. Otherwise
once a file from a project is touched in VE the Compile Single will
not work for all project files. Is that true Martin?

I guess there might be other project actions influenced by that. Would
need evaluation from project team what actually got broken by two
projects being opened for the same FO and how large/small the impact is.
Comment 27 Jan Chalupa 2004-12-09 12:16:42 UTC
Is the Versioning manager the only way to trigger this?
Comment 28 Martin Entlicher 2004-12-09 12:51:07 UTC
Perhaps the fix can be made also in projects - not to allow to open
two projects for a single physical file.

Versioning Manager has nothing to do with this; Versioning Explorer
must not be touched in order the Compile File (and other projects
actions) work.
Comment 29 Martin Entlicher 2004-12-09 12:53:11 UTC
And yes, Versioning Explorer is currently the only known component to
trigger this.
Comment 30 Jesse Glick 2004-12-10 22:07:57 UTC
So let's say a release note for 4.0: avoid opening files from the
Versioning Explorer except for pure inspection (never run actions on
them). Enough?
Comment 31 Martin Entlicher 2004-12-13 11:23:09 UTC
Unfortunately, this is not enough. It's not possible to open files
from Versioning Explorer anyway. It's more serious, the Versioning
Explorer can not be used nearly at all. You can expand it's nodes, but
you must not select any node. As soon as you *select* any folder or
file that reside in some project, that project will loose the
file-based actions.

So I would recommend: Do not use the Versioning tab or "Show Versions"
context action if you need to compile/run/debug individual files.
Comment 32 Jesse Glick 2004-12-14 03:04:12 UTC
Wouldn't that make this a P1 bug suitable for merging then?
Comment 33 Jan Chalupa 2004-12-14 05:59:06 UTC
Too late for merging into 4.0. The fix is known, but it will take more
time to test it. A hotfix should be put on the update center after
it's sufficiently tested, but we won't hold the release for this.
Comment 34 Milan Kubec 2004-12-14 08:33:02 UTC
Could anybody (Martin, Jesse?, David?) elaborate on this issue a bit?
Is it the problem only in VCS or is there something that could be
fixed on projects side? Martin has mentioned that one project is
opened twice - is it problem of project infrastructure? Or is VCS
using something that is not supported or even deprecated. Please
describe the fix as well, it's highly probable that the fix will go to
AUC as hotfix. Thanks.
Comment 35 David Konecny 2004-12-14 09:34:40 UTC
The problem is in VCS. Could be perhaps worked around on projects
side, but I would rather fix the cause.

The purpose of introducing MasterFS in IDE was to guarantee that one
java.io.File is always represented by one FileObject without regard of
used underlying NB Filesystem (e.g. LocalFS, VCS FS). All modules and
functionality rely on that. Unfortunately this got broken
(unintentionally) by Versioning Explorer which exposes directly VCS
FileObjects.
Comment 36 Martin Entlicher 2004-12-16 21:06:43 UTC
Merged into release40_fixes branch, will put into HotFixes AU:

/shared/data/helm/cvs/repository/vcscore/manifest.mf,v  <--  manifest.mf
new revision: 1.49.6.1.2.1; previous revision: 1.49.6.1

/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FileNode.java,v
 <--  FileNode.java
new revision: 1.9.14.1; previous revision: 1.9

/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FileSystemNode.java,v
 <--  FileSystemNode.java
new revision: 1.4.6.1; previous revision: 1.4

/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FolderChildren.java,v
 <--  FolderChildren.java
new revision: 1.6.16.1; previous revision: 1.6

/shared/data/helm/cvs/repository/vcscore/src/org/netbeans/modules/vcscore/versioning/impl/FolderNode.java,v
 <--  FolderNode.java
new revision: 1.10.12.1; previous revision: 1.10
Comment 37 Peter Pis 2005-04-13 13:06:36 UTC
Verified.