Community
Participate
Working Groups
We like to maintain the .project and .classpath files in our SCM which currently is SourceSafe. Since we run VSS in lock mode this means that these files are stored as read-only files unless they are specifically checked out. If you try to run a refactoring, in this case renaming a .java file, and you select the "Preview" button on the refactoring dialog and you have any of the check-boxes in the new refactoring dialog checked, therefactoring will fail and will display the following message in the refactoring dialog. Internal error while creating a change object. See log for details. I was hoping that I would get a list of the files that would be affected by the refactoring so that I could check them out. The relevant portion of the log is attached. Note that the file that was to be renamed is not part of the project that is being complained about in the log file. It looks as if it is necessary to have all .project and .classpath files read-write to even find out what files would be affected by a refactoring. Regards Jonathan Gossage
Created attachment 2942 [details] Relevant portion of .log file.
Some additional information on the environment that created this problem We are usig the new flexible project structure support. I note that near the end of the log Eclipse is complaining that the directory Release/com/apple/mrj does not exist in project CryptoadminApi. On our system, the directory "Release" is a link to another directory, so it may be possible that the link is not being honoured. Regards Jonathan Gossage
Yet more information. The path Release/com/apple has been excluded from the CryptoadminApi. Regards Jonathan Gossage
Somehow JDT Core wants to update the classpath due to searching/indexing, which got triggered by refactoring's precondition checking. The type rename refactoring doesn't manipulate the .project/.classpath file. Moving to JDT/Core.
Jonathan - do you remember if you had more projects in your workspace (which used to be prereq'ed but were missing before - or reciprocally projects that disappeared since last time around ?). The first 2 stacktraces are startup related. When we are about to check our index consistency, we force classpath resolution, which wakes up some container initializer, ending up updating some classpath. This has the consequence of attempting to modify the prereq project list (.project), and apparently this is failing to succeed, though a definition update is supposed to check out the corresponding file. I think we are only adding existing projects as prereqs, as opposed to any being referenced (no matter if it actually exists), which sounds fair. This could explain that at the moment the container is initialized, we update the classpath and notice only at that time the project prereq addition/deletion. A simple fix would be to ignore project existence when adding prereq project references, need to check some more. Also why is the checkout of .project not working ? Is it not occurring if during startup ?
John - can you comment on the .project not being checked out for free ?
All SCM operations have to be performed outside Eclipse in our environment since we have found the SourceSafe team plugin to be unreliable. In addition, with the addition of links in M4 which this plugin does not understand, the plugin has become totally unusable. Therefore, since we use SourceSafe in locking mode, all files that have not been explicitly checked out in advance will be read-only, and I doubt that Eclipse would be able to do an automatic checkout itself, given that there is no team plugin installed. So this is the reason why the .project file was read- only.
Ok, I understand now... are you positive that no project got added/removed in between the two sessions ?
This was a single run and the two log entries were only a few minutes apart. If anything happened it was not apparent. Regards Jonathan Gossage
Smells related to bug 29585. No .classpath/.project change should occur when a container/variable is initialized.
Jonathan, according to the stack trace, the exception occured during the workbench startup, not during refactoring. Can you confirm this?
I was getting the same symptom both at workbench startup and when making a refactoring request. I only discovered that I was also getting this during startup after filing the bug report. Regards Jonathan Gossage
Thanks Jonathan. Looking at the code, I don't understand how this can happen. In the newsgroup I saw you're having problem with your workspace (might be corrupt). Can you try to reproduce this problem by creating a new workspace, and by checking out your projects with VSS? If you still have the problem, could you please attach your .project and .classpath file to this bug?
Created attachment 3013 [details] Contains all .project and .classpath files
Sorry Jonathan, but I still cannot reproduce the problem. I created a workspace with the .classpath and .project files you attached, and when I start it up, it goes smoothly. Note that I had to bind the classpath variables to fake jars as I don't have those. Were you able to reproduce the problem in a new workspace?
Things seem to have gone down-hill for me. It looks as if I am going to have to completely rebuild everything in my workspace since I tried to rename my projects. This resulted in my losing the link information in the .project files and even after restoring this information by hand Eclipse could no longer see any source files in my projects. I am going to rebuild the environment and retry the original problem then. It really looks to me, though, as if the new link facility is very fragile at the moment and needs a good deal of hardening. Once we get through these problems, I have several more apparently link related problems to report.
I would encourage you to log other link-related problems as soon as possible. We are currently going through a mini test pass to clear up problems related to linked resources. Reporting the problems as soon as possible increases the chance that we are able to fix them before M5.
I rebuilt my workspace and I now get a different symptom when I try to rename a file. Now when the "Rename Compilation Unit" dialog comes up, the "Preview" and "OK" buttons are disabled but no explanation is given as to why this should be so. I suspect that it is because all files are read-only since they have not been checked out from SourceSafe. I also tried checking out the file I was trying to rename and then renaming it but I got the same symptom. Regards Jonathan
Jonathan, so you didn't get the exception on startup this time? In this case I will close this bug (unless you say otherwise). For the problem with the disabled buttons, please open a separate bug against JDT UI.
Thats fine. Regards jonathan Gossage
Closing
