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.
Development build #200504031800 of NetBeans 4.1 Windows XP, JDK 1.5.0_03 build #06 Description: ============ Developers using PVCS or VSS might get their projects into an inconsistent state when library seems to be added/removed however it was only done in a half way. This results in impossibility to run project. It is caused by the fact that these version control systems use read-only access for files that are currently not being worked on. The strange thing though is that two files (project.xml and project.properties) are modified fine while build-impl.xml and genfiles.properties remain untouched. The project for example still requires the libraries although they are not referenced from project.xml and project.properties. Steps to reproduce: =================== 1. Register some PVCS working directory in Versioning Manager. 2. Create new sample web application project in this directory. 3. Switch to "Files" view and "PVCS|Add All" whole project into PVCS archive. 4. Get back to "Projects" view and "Add Library..." e.g. JSTL to the project. 5. You will be prompted to confirm getting project.xml and project.properties files but no such dialogs will show up for build-impl.xml and genfiles.properties files. Workaround: =========== Prior changing any property of project, switch to "Files" view and invoke "PVCS|Get" on "<project_name>|nbproject" node, check "Check out writable workfile" option and push "OK" button.
Did you test a similar scenario for j2se project? It is always useful to try this to see if the problem is in web project code or more generally in projects code and note this in issue. I do not see anything web project does differently for project and properties files and not for build files.
So far it seems that this is web project specific. Using J2SE project type I was not able to modify other than project.properties configuration file which invokes appropriate VCS edit action correctly. If you find out how to modify build-impl.xml or genfiles.properties using project customizer, it can be reassigned to projects component.
Try this, please. Open project properties, Sources tab, choose Add Folder (any folder). When I do this it modifies project.xml, genfiles.properties and build-impl.xml. Thanks for testing this (I do not have vss or pvcs installed).
Yes, you are right. The same problem occurs in J2SE project if I want to add/remove additional source package folder. This results in impossibility to run such project: D:\Tests\PVCS\Work4\JavaApplication2\nbproject\build-impl.xml:85: Must set src.Zdrojaky.dir BUILD FAILED (total time: 0 seconds) Reassigning to project component for investigation why the behaviour is different for project.properties and build-impl.xml files.
Is there a UserCancelException printed somewhere to the log? That is my only guess.
Created attachment 21405 [details] Messages log from that IDE session.
Acc. to the stack trace, your working dir is read-only and you do not have "Call EDIT Command when Editing Read-Only Files" enabled for the VCS mount, so there is nothing the project system can do. Reopen with a new messages.log if there is still a problem when edit-on-lock mode is used.
Of course I DO have "Call EDIT Command When Editing Read-Only Files" option checked. If I hadn't, project.properties and project.xml files wouldn't be modified. Please fix this problem for remaining two files (build-impl.xml and genfiles.properties). Reopening in development build #200504062223 of NetBeans 4.1.
Then Martin E., why does the stack trace indicate that the checkbox is not selected? Please look at it.
Starting to look at it... There is really no UserQuestionException thrown in the log file. Will try to reproduce and find out why...
There is a problem in VCS, but even when UserQuestionException is thrown for *all* files, I get prompt only for the two mentioned. So I guess that there is still a bug in the project code. I've submitted issue #57636 for the problem in VCS.
Created attachment 21471 [details] The stack traces from calls to VcsFileSystem.lock(). Might help to locate the problem.
FYI: the unreliability in VcsFileSystem.lock() behavior is caused by the calls comming in AWT. Is it really O.K. to do all this work in AWT?
Was actually intentionally implemented this way. Since build-impl.xml can be regenerated at any time, I skipped code to ask the user the about it. The user can simply ask to edit the file, delete it, then close and reopen the project. However few would figure this out.
Please test attached patch. I do not have the environment needed to actually try it, I think.
Created attachment 21556 [details] Possible patch (compiles and passes unit test but otherwise untested)
committed Up-To-Date 1.12 ant/project/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java
I am gonna verify the fix today. Downloading the latest continuous trunk build ...
Hm, it seems like PVCS support got seriously broken in latest 4.2 build #20050412-0609. I am unable to add anything into PVCS archive now. I will investigate this problem with Martin first and put our conclusion here.
First of all, there is a regression in PVCS profile (#57771) which caused my previous comment however it shouldn't be related to this issue. Secondly, the problem described here is only a little bit better with Jesse's patch. However, there are still three problems. Trying to verify in continuous trunk build #20050412-0609 of NetBeans 4.2. 1. I have experienced 2 deadlocks when trying to verify the patch. This obviously gets project files into an inconsistent state. Thread dumps attached. 2. IDE shows very funny dialog asking "Do you want to get a writable file?" with only "OK" button without possibility to answer "No". Screenshot attached. 3. A lot of exceptions are thrown into console. IDE log attached. I have found out that problems 1 and 2 can be avoided by unchecking "Prompt for EDIT Command Execution" advanced option of PVCS entry in Versioning Manager. This could be used as partial workaround.
Created attachment 21574 [details] Thread dump with one deadlock of IDE.
Created attachment 21575 [details] Thread dump with another deadlock of IDE.
Created attachment 21576 [details] Screenshot of funny question. How to say "No !" ?
Created attachment 21577 [details] IDE log from the verification session.
#2 is not coming from ant/project, I presume it is coming from VCS? Please file separately. Exceptions in #3 probably unrelated to this bug, please file separately. Looking at #1 only.
I have managed to set up a local CVS repo with watches in which I am able to reproduce the problem, I think. I actually get prompted for all four files (not just project.xml and project.properties but also build-impl.xml and genfiles.properties - I think; the dialogs do not always state the file name!), but though I accept in all cases, only project.* are modified; build-impl.xml is locked but not modified, and genfiles.properties is not locked at all. Something weird... my handlers in AntProjectHelper and ProjectProperties seem to be working, but not the one in GeneratedFilesHelper. Seems to have something to do with the fact that I am trying to acquire *both* locks (gf.props and b-i.xml) before proceeding, which seems safest. Looks like what happens is - first attempt to lock b-i.xml fails, UQE thrown - GFH catches it, tries again - next time, locking b-i.xml succeeds (already edited), but locking gf.props fails with UQE - this UQE is just printed to console and write aborts Looks like I need to catch UQE *twice* (but not three times). Jezis marja.
I have also observed the deadlock (but randomly). Seems to be caused by fix of issue #50198.
I filed issue #57791 for the deadlock, which I think is a separate issue.
Have patch. Need to catch UQE twice. Then all files are correctly modified. I cannot reproduce #2, the odd-looking dialog. Probably PVCS-specific. Please file separately in vcsgeneric. The dialog when using CVS is not great either - doesn't tell you *which* file you are about to edit - but at least it gives you an option to cancel. (If you do cancel locking the files, your changes in the properties dialog are correctly reverted, as far as I can tell. Did not try cancelling locking of some files and not others, but anyone who does that probably deserves whatever they get.)
Please verify. committed Up-To-Date 1.13 ant/project/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java
Complete diff including both fixes: http://www.netbeans.org/source/browse/ant/project/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java?r1=1.13&r2=1.11
The patch seems good. Catching the UQE twice is hopefully enough (once for build-impl.xml, once for genfiles.properties)
Okay, downloading latest continuous trunk build again ... I will hopefully verify the other issues filed by Jesse too. =:-)
I have tested continuous trunk build #20050413-0713 of NetBeans 4.2 and current behaviour is significantly better. I am really not sure if the fix is mature enough to be integrated into release41 branch though. There are still the following problems: 1. The question dialog does not display the name of file to be got from PVCS archive. Thus user does not know what s/he is in fact confirming. 2. Trying to cancel locking the files is obvious road to hell. All attempts lead to serious slowdown of IDE performance and consequent crash of JVM (!) immediately or in several minutes. Attaching one of log files. This can be caused by running pcli.exe process which consumes ~90% of CPU. Martin Entlicher should explain its purpose in more detail. 3. I also got into a state when IDE had to be killed since it was in kind of UI lock. Classpath scanning started but didn't finish probably because of waiting until some configuration file could be modified. Attaching screenshot. I couldn't do anything since the scanning dialog was modal.
Created attachment 21609 [details] 1 out of 3 JVM crash logs.
Created attachment 21610 [details] Screenshot of UI deadlock. IDE had to be killed.
I will look at the new #2 and #3 today. Sigh. But to investigate a deadlock or 100% CPU usage I need some thread dumps - especially as I cannot reproduce any such problem using CVS. (Please try with CVS as well, for purposes of comparison - and any bugs that occur only with PVCS should probably be filed in vcsgeneric.) Re. the new #1 (no name of file in dialog): again, please do not report that here. File a separate bug in vcscore for it. I am following the exact instructions given in the Javadoc for UserQuestionException: "The <code>getLocalizedMessage</code> method should return the user question, which will be shown to the user in a dialog with OK, Cancel options and if the user chooses OK, method <code>ex.confirmed ()</code> will be called." That is what ant/project does. If the localized message does not specify the name of the file, that is the fault of some vcs* module, since ant/project is displaying UQE.gLM() as it receives it from the filesystem.
The missing file name is a problem of vcsgeneric. Jiri, please file an issue for that (to vcsgeneric component). It did not impose a problem when the user was confirming a dialog in Editor, but now it looks really strange. (But the implementor of the dialog can add the file name to the dialog title.)
Note: a better solution would be to (try to) lock various files when the properties dialog is *opened*, rather than when it is closed and changes must be saved. This is filed as issue #50992 (in a somewhat different context). However I think this would require API changes and is likely to be more complex than the current approach.
Re. JVM crash - surely a bug in the JVM, file it if you can reproduce. Does not look like it has anything to do with this bug. Re. permanent scanning dialog - I filed as #57855 for vcscore. Re. 100% CPU - cannot reproduce, but sounds like a bug with PVCS? Best to file separately. One problem I could reproduce but can't fix: if the classpath scanning dialog appears, it seems to act as if you had agreed to edit the file which was currently being prompted for, without you clicking OK or hitting Enter. This is probably a bug in the window system or something, I guess. May be related to issue #57855. If you disable the scanning dialog - using the experimental flag to show status only in the toolbar - this does not occur. And in fact in that case, everything works as expected: 1. If you change platform or add a subproject, scanning occurs when you close the properties dialog and the Libraries node shows the new selection, but if you cancel edits, scanning occurs again and the Libraries node is correctly reverted to its previous state. 2. If you accept edits but then use e.g. "cvs up -C" to revert them (and unlock the files), when you switch back to NB it automatically reverts the Libraries node to the state you had originally checked out. So for now at least, I do consider this bug fixed in its essentials, but it is clear there are other problems in various areas (not mine, I believe) which should be reported separately if they can be reproduced. Whether it is still desirable to merge the current fixes to release41 is another question. Personally, my recommendation is that anyone using VCS integration not use exclusive locks at all, but that is another matter. If you do use exclusive locks, it seems best to uncheck the option to prompt for editing/locking (i.e. have the IDE do it automatically), *and* disable the classpath scanning dialog.
Okay, since current behaviour is _significantly_ better I agree with the fix and have no objections against merging your patch to release41 branch. BTW, exlusive locking concept is simply how systems like PVCS and VSS work. Martin, couldn't you even remove the only checkbox "Lock for the Current User" from the simple version of "PVCS|Get" dialog so that user does not have to confirm really anything ? I guess it's too late now :-( but it would be wonderful workaround ... :-) Going to change resolution once verified in 4.1 ...
"Lock for the Current User" should be checked on by default - we should fix this in 4.2. Regarding the dialog itself, it might be pretty common to also apply the lock, but when the user does not want to (or knows that they can not to - e.g. because there is already a lock from someone else), so I'm not really sure about this.
committed Up-To-Date 1.11.4.1 ant/project/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java
Verified in RC1 candidate build #200504171930 of NetBeans 4.1.