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.
[ 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.
Not sure what is the right component, reassigning to java/project for eval.
Milan please check for reproducibility with more precise steps.
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.
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.
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.
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.
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.
This is really strange and seems to be related to VCS support. Martin please evaluate. Re-assign if the root cause is somewhere else.
Reproducible for me even when I set offline CVS mode.
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!
Reproducible on 4.0 Beta2 too.
Reproducible on my linux too.
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...
Created attachment 19178 [details] Description of what is happening when a file on Versioning tab is selected.
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.
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.
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 ??
"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
FIXED.
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...
Created attachment 19211 [details] Problems that occured after this fix.
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.
Will target milestone still be 4.1 or will it be fixed in 4.0??
Martin, please provide workaround for 4.0 (if there is any), since I doubt we can put it into 4.0 now.
There is no workaround other than a restart of NetBeans.
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.
Is the Versioning manager the only way to trigger this?
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.
And yes, Versioning Explorer is currently the only known component to trigger this.
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?
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.
Wouldn't that make this a P1 bug suitable for merging then?
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.
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.
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.
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
Verified.