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 57480 - Can't add/remove library to/from web project in PVCS/VSS.
Summary: Can't add/remove library to/from web project in PVCS/VSS.
Alias: None
Product: projects
Classification: Unclassified
Component: Ant Project (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on: 46089 50992 57636 57748 57855
  Show dependency tree
Reported: 2005-04-05 14:25 UTC by Jiri Kovalsky
Modified: 2006-03-24 12:47 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Messages log from that IDE session. (27.50 KB, text/plain)
2005-04-06 06:35 UTC, Jiri Kovalsky
The stack traces from calls to VcsFileSystem.lock(). Might help to locate the problem. (26.73 KB, text/plain)
2005-04-07 18:56 UTC, Martin Entlicher
Possible patch (compiles and passes unit test but otherwise untested) (9.49 KB, patch)
2005-04-11 19:21 UTC, Jesse Glick
Details | Diff
Thread dump with one deadlock of IDE. (30.23 KB, text/plain)
2005-04-12 15:32 UTC, Jiri Kovalsky
Thread dump with another deadlock of IDE. (33.74 KB, text/plain)
2005-04-12 15:32 UTC, Jiri Kovalsky
Screenshot of funny question. How to say "No !" ? (20.77 KB, image/jpeg)
2005-04-12 15:33 UTC, Jiri Kovalsky
IDE log from the verification session. (61.48 KB, text/plain)
2005-04-12 15:34 UTC, Jiri Kovalsky
1 out of 3 JVM crash logs. (12.79 KB, text/plain)
2005-04-13 13:32 UTC, Jiri Kovalsky
Screenshot of UI deadlock. IDE had to be killed. (21.71 KB, image/jpeg)
2005-04-13 13:33 UTC, Jiri Kovalsky

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Kovalsky 2005-04-05 14:25:53 UTC
Development build #200504031800 of NetBeans 4.1
Windows XP, JDK 1.5.0_03 build #06

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 are modified fine while build-impl.xml and remain untouched. The project for example still requires the
libraries although they are not referenced from project.xml and

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
files but no such dialogs will show up for build-impl.xml and files.

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.
Comment 1 Pavel Buzek 2005-04-05 14:42:48 UTC
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.
Comment 2 Jiri Kovalsky 2005-04-05 15:06:14 UTC
So far it seems that this is web project specific. Using J2SE project type I was
not able to modify other than configuration file which
invokes appropriate VCS edit action correctly. If you find out how to modify
build-impl.xml or using project customizer, it can be
reassigned to projects component.
Comment 3 Pavel Buzek 2005-04-05 15:20:39 UTC
Try this, please. Open project properties, Sources tab, choose Add Folder (any
folder). When I do this it modifies project.xml, and
Thanks for testing this (I do not have vss or pvcs installed).
Comment 4 Jiri Kovalsky 2005-04-05 15:34:24 UTC
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
BUILD FAILED (total time: 0 seconds)

Reassigning to project component for investigation why the behaviour is
different for and build-impl.xml files.
Comment 5 Jesse Glick 2005-04-05 22:54:21 UTC
Is there a UserCancelException printed somewhere to the log? That is my only guess.
Comment 6 Jiri Kovalsky 2005-04-06 06:35:29 UTC
Created attachment 21405 [details]
Messages log from that IDE session.
Comment 7 Jesse Glick 2005-04-06 16:18:29 UTC
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.
Comment 8 Jiri Kovalsky 2005-04-07 15:11:35 UTC
Of course I DO have "Call EDIT Command When Editing Read-Only Files" option
checked. If I hadn't, and project.xml files wouldn't be
modified. Please fix this problem for remaining two files (build-impl.xml and

Reopening in development build #200504062223 of NetBeans 4.1.
Comment 9 Jesse Glick 2005-04-07 16:29:38 UTC
Then Martin E., why does the stack trace indicate that the checkbox is not
selected? Please look at it.
Comment 10 Martin Entlicher 2005-04-07 18:00:40 UTC
Starting to look at it... There is really no UserQuestionException thrown in the
log file. Will try to reproduce and find out why...
Comment 11 Martin Entlicher 2005-04-07 18:55:14 UTC
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.
Comment 12 Martin Entlicher 2005-04-07 18:56:25 UTC
Created attachment 21471 [details]
The stack traces from calls to VcsFileSystem.lock(). Might help to locate the problem.
Comment 13 Martin Entlicher 2005-04-08 13:57:21 UTC
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?
Comment 14 Jesse Glick 2005-04-11 18:48:23 UTC
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.
Comment 15 Jesse Glick 2005-04-11 19:21:21 UTC
Please test attached patch. I do not have the environment needed to actually try
it, I think.
Comment 16 Jesse Glick 2005-04-11 19:21:55 UTC
Created attachment 21556 [details]
Possible patch (compiles and passes unit test but otherwise untested)
Comment 17 Jesse Glick 2005-04-12 01:02:58 UTC
committed     Up-To-Date  1.12       
Comment 18 Jiri Kovalsky 2005-04-12 09:11:40 UTC
I am gonna verify the fix today. Downloading the latest continuous trunk build ...
Comment 19 Jiri Kovalsky 2005-04-12 10:57:24 UTC
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.
Comment 20 Jiri Kovalsky 2005-04-12 15:30:57 UTC
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.
Comment 21 Jiri Kovalsky 2005-04-12 15:32:21 UTC
Created attachment 21574 [details]
Thread dump with one deadlock of IDE.
Comment 22 Jiri Kovalsky 2005-04-12 15:32:52 UTC
Created attachment 21575 [details]
Thread dump with another deadlock of IDE.
Comment 23 Jiri Kovalsky 2005-04-12 15:33:47 UTC
Created attachment 21576 [details]
Screenshot of funny question. How to say "No !" ?
Comment 24 Jiri Kovalsky 2005-04-12 15:34:40 UTC
Created attachment 21577 [details]
IDE log from the verification session.
Comment 25 Jesse Glick 2005-04-12 18:31:39 UTC
#2 is not coming from ant/project, I presume it is coming from VCS? Please file

Exceptions in #3 probably unrelated to this bug, please file separately.

Looking at #1 only.
Comment 26 Jesse Glick 2005-04-12 19:59:53 UTC
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 but also build-impl.xml and - 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 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.
Comment 27 Jesse Glick 2005-04-12 20:30:54 UTC
I have also observed the deadlock (but randomly). Seems to be caused by fix of
issue #50198.
Comment 28 Jesse Glick 2005-04-12 20:37:44 UTC
I filed issue #57791 for the deadlock, which I think is a separate issue.
Comment 29 Jesse Glick 2005-04-12 22:21:44 UTC
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.)
Comment 30 Jesse Glick 2005-04-13 00:19:59 UTC
Please verify.

committed     Up-To-Date  1.13       
Comment 32 Tomas Zezula 2005-04-13 09:19:59 UTC
The patch seems good.  Catching the UQE twice is hopefully enough (once for
build-impl.xml, once for
Comment 33 Jiri Kovalsky 2005-04-13 10:35:04 UTC
Okay, downloading latest continuous trunk build again ... I will hopefully
verify the other issues filed by Jesse too. =:-)
Comment 34 Jiri Kovalsky 2005-04-13 13:30:09 UTC
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.
Comment 35 Jiri Kovalsky 2005-04-13 13:32:17 UTC
Created attachment 21609 [details]
1 out of 3 JVM crash logs.
Comment 36 Jiri Kovalsky 2005-04-13 13:33:37 UTC
Created attachment 21610 [details]
Screenshot of UI deadlock. IDE had to be killed.
Comment 37 Jesse Glick 2005-04-13 14:00:26 UTC
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.
Comment 38 Martin Entlicher 2005-04-13 15:57:18 UTC
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.)
Comment 39 Jesse Glick 2005-04-13 22:16:04 UTC
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.
Comment 40 Jesse Glick 2005-04-13 22:55:50 UTC
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

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.
Comment 41 Jiri Kovalsky 2005-04-14 18:52:31 UTC
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 ...
Comment 42 Martin Entlicher 2005-04-15 15:09:00 UTC
"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
Comment 43 Jesse Glick 2005-04-15 19:41:17 UTC
committed     Up-To-Date   
Comment 44 Jiri Kovalsky 2005-04-18 13:31:28 UTC
Verified in RC1 candidate build #200504171930 of NetBeans 4.1.