Community
Participate
Working Groups
In a Java based project, I sometimes use manual CVS updates and commits and also compile files outside Eclipse. This used to work when I used "Refresh" on the Eclipse side, or deleted the directory bin/ with the compiled Java binaries. Sometimes I got the error "Save could not be completed. Reason: <projectname> does not exist.". A "Rebuild all" did not produce anything. Usually "Refresh" took care of this and made the error go away - up to now. I have deleted the project directory, checked it out again from CVS, tried again - still the same. I have deleted the entire workspace (all projects + metadata) - and it still does not work anymore. Now I am lost about what I should do next. In general I have found that Eclipse is very, very fragile once someone does even simple things such as editing a file outside eclipse. It should be much more stable with respect to that and refresh files automatically (use the time stamp of a directory for a quick check whether anything in it has changed).
Are there more error details in your .log file? Please attach here if available. By the way, directory timestamps don't change when files within them change.
There is one entry in the log file every time this happens: !ENTRY org.eclipse.jdt.core 4 969 Aug 14, 2003 10:49:07.661 !MESSAGE pax does not exist. The log entry is only that, and it does not say much more than the error message.
Please do not adjust bug priority. Priority is for developers to prioritize the work and severity is for the user to indicate the importance to them. The Eclipse Bugzilla Help document can be found here: https://bugs.eclipse.org/bugzilla.html There is an auto-refresh plug-in which will check the file system in background and prompt the user to bring the changes into Eclipse. I believe that it is only available for Windows and Linux but we would be happy to accept a contribution to the Mac platform. The download is available from the Platform/Core team web space. (eclipse.org -> projects -> Eclipse Platform -> Platform -> Core -> Development Resources) Note that it is not recommended that users manually manipulate the files in the project metadata area. Moving to JDT/UI for comment. Perhaps we can track down the error message and determine the case where this is happening. (I'm guessing the "Save cannot be completed" message is generated in the UI)
Comment from user who got this problem: Note that the .metadata directory was never changed manually, only deleted after a couple of fruitless attempts to sync Eclipse with the file system using "Refresh" or a new project checkout. The only manual changes were in the project file space: a) CVS usage, replacing files and using a canonic CVS/Root. (I use public key authentication which Eclipse is not capable of handling.) b) Editing source code. c) Compiling files. Changes in the "bin" directory could usually be reconciled with Eclipse by erasing it completely and then rebuilding the project with Eclipse. However, at present, Eclipse refuses to work even with a completely fresh project checkout (all project files deleted), with said error message and log entry ("<projectname> does not exist").
Can you please indicate which build you are using. This is very likely a JavaModelException indicating that the project doesn't exist in the Java model anymore. The question is why ? Cyrille, do you still see the project mentioned in the error message in the navigator and the package explorer. If so can you please close the package explorer and reopen it via Windows->Show View->Package Explorer.
Yes, the project is fully visible in the package explorer. I can browse the project and view any file normally, but not save it after editing. Closing and re-opening all views or even all perspectives does not solve this problem.
Cyrille which build are you using ? Moving to JDT/Core for comments.
We clearly need more details on how to reproduce it. Build number is required and steps to reproduce from a fresh workspace would be a great help to fix it.
Change milestone.
The build I use is 3.0M2. I have originally entered this in my first bug report under "target build", but apparently it was not meant to be used for this. How I can now reproduce this bug: 0) Start fresh: Close project, delete all project files, but not metadata. 1) Add new repository location, check out project P using ssh. (No problems or errors here.) 2) In the navigator, open a file (source is in src/P/packagename/XY.java). 3) Type a space, delete it, try to save. 4) "Save could not be completed. Reason: P does not exist." Note: There is no log entry for trying to save the file. The latest log entry is from the CVS command: "!MESSAGE Host 'SERVER' is running unsupported CVS version 1.11. Although most functionality works, use version 1.11.1p1 or later for full support." Probably the log entries were from the compiler. Currently, without setting the project preferences again, nothing happens when I select "Project/Rebuild All". Eclipse has not been behaving like this right after installation, but once this has started, even deleting /usr/local/eclipse/workspace/.metadata along with all project directories has not solved this problem. I have only tried deleting the .metadata once, but will do it again if really needed (although I would prefer not to lose all settings again).
So you mean that if you start a fresh workspace (do not preserve .metadata) everything works fine. This means that your workspace metadata are corrupted. I doubt we can do anything from there. Have you tried a newer build like the latest integration build? We need to understand why the metadata got corrupted. Can you report any specific crash? As a workaround, you can export your preferences to an external file and then start a new workspace from scratch and import your preferences. Like this you should be able to preserve your existing settings.
No, even deleting the workspace and then using Eclipe from scratch no longer helps. I.e., rm -r /usr/local/eclipse/workspace mkdir /usr/local/eclipse/workspace and then starting Eclipse results in the loss of all metadata, but the bug still behaves exactly as described above. I will try the latest integration build.
The error persists when I use a totally fresh Eclipse-3.0I20030820 install. The CVS settings are: 1) Abbreviated host name (not full host.domain.... but just host), which is correctly resolved. 2) Full absolute path name for CVS Root. 3) User name and password (!) even though public key authentication is set up, which Eclipse cannot recognize or use. 4) "extssh" as authentication method. I then use "checkout" with the default path name for the head revision of the project and proceed with mock-editing the file, as described above. Saving the file is not possible ("P does not exist"). However, the files are fully present on the system and also writable.
I tried retrieving org.eclipse.jdt.ui source from dev.eclipse.org using extssh and I could not reproduce your issue. Could you please describe your project layout? What do you mean by "source is in src/P/packagename/XY.java"? If the file is in the project P, then the path should be /P/packagename/XY.java. Could you please zip your project P and attach it to the PR? Do you have the same problem when you create all files directly on the file system instead of using CVS checkout?
Unfortunately I cannot send any project files to you. The project layout is as follows (only directories listed, certain subdirectories omitted for brevity): P |-- bin | |-- (compiled files will be here) |-- doc |-- javadoc | `-- P `-- src |-- P | |-- package1 | |-- package2 | `-- ... |-- propertyFiles `-- tests Trying manually checked out sources works fully: 1) Delete /usr/local/eclipse/workspace, start Eclipse, close it for a fresh install. 2) checkout sources to /tmp 3) Restart Eclipse. 4) Create new project P. 5) Import file system from /tmp/P to P (using selected files, selecting all files so only relative path names are used). This results in P/src and all the other subdirectories, instead of P/private/tmp/src. 6) Switch setting to JDK 1.4, compile - it works! I can also save files after editing. However, this way, I lose any CVS support; all CVS and CVS/* directories show up in the Navigator, making it nearly useless. So it seems the bug only occurs when I check out the files from CVS within Eclipse! CVS outside Eclipse and then importing works. As a workaround, I now only have to get rid of the CVS/* files in the Navigator/Package Explorer etc.
Could it be because you are not using the proper version of CVS? Move to Platform/VCM for comment.
Add CC'.
About the CVS version: I cannot upgrade the CVS client (Concurrent Versions System (CVS) 1.11 (client/server)) running on the file server, and I am not sure how fast an upgrade request on the server can be carried out. NOTE: Eclipse used to work normally with CVS (extssh plugin) for a few days, so I am not sure whether upgrading the server will help. But if you think it makes a difference, I will ask the overworked sysadmins to try it.
The bug is independent of the CVS version used. I installed cvs 1.11.6 temporarily on the file server under my home directory, and the bug still persists.
Did this problem occured on Mac OS X?
Yes, I only have a MacOS X system to run Eclipse on at the moment. The exact version is 10.2.6, build 6L60.
I think I know what the problem is: Trying to save a Java file in a non-Java project results in the problem described above. Since I'm at home I could only verify on MacOS X, but I'm sure that the problem occurs on all platforms.
Created attachment 5808 [details] stacktrace The corresponding stacktrace where the JavaModelException is thrown.
If my analysis is correct, then the severity of this problem doesn't seem to be "blocking". It's more an user error.
Problem occurs on Win2k too. Setting Platform/OS to All.
I do not consider this to be a user error, though. It should always be possible to save an edited file, even if it does not compile. I do not understand why Eclipse does not recognize a project as a Java project when checked out from CVS. Is there an easy way to convert it to a Java project automatically? Can this be detected upon CVS checkout? Shouldn't "Project/Rebuild Project" inform the user of something?
A java project has a java nature in the .project file. What is the contents of your .project file for your project P? You need to find this: <natures> <nature>org.eclipse.jdt.core.javanature</nature> </natures> in your .project file. If this problem is not specific to MacOS, it should not be tagged as a MacOS problem.
The problem is that not everyone is using Eclipse, or the same version of it. Older versions had a .vcm_meta (sp?) file, newer ones have a .project file, and the .project file is not fully compatible across major releases (2.X vs 3.0 builds). Is there way to "cast" a project to a Java project? I wonder what makes it so difficult for Eclipse to deal with the lack of a .project file when using CVS. A simple file import with a fresh .project file produces correct results. Couldn't a Java project also be identified by the overwhelming number of .java files in the directories? By default, the project build would then compile *all* .java files in a project starting from the top-level which can be determined from the package name. But as I said, the files are already set up such that everything compiles well when importing the files into an empty Java project.
*** Bug 41885 has been marked as a duplicate of this bug. ***
In response to Andre Weinand's comments of 8-21: I believe the priority for this should stay at blocker. Unlike the OP for 41583, the problems reported in 41885 happen out of the box on MacOS X without using CVS. All one needs do is create a project based on existing source in the filesystem, and M2 will not be able to create a working project, where M1 would. (See 41885 for details.) There is no user interaction involved, save having pre-existing source, lib, and build directories. Scott
Moving to JDT/Text since they perform the actual savc.
Upon opening the (compilation unit) document provider should be smarter and not connect the file to the Java Model if the file is not on the build path. There's not only a problem on save: when opening there's one exception after the other and also while typing the reconciler produces exceptions. Reducing to 'critical' since this isn't a blocker: after the first save error you can save without problems. Also adapted summary. Please note that when you open a file that does not end with *.java you get an error dialog (reported by JDT Core). After confirming the dialog you can edit and save the file. See bug 41099 for more details.
Logic for reducing to critical from blocker is incorrect for bug 41885. You CANNOT create a new java project in M2, no matter how many times you save. It does not work the second time, the third time, or any later time. The project is not created, and thus no java nature is assigned
We think Java Core could be more tolerant as it is with *.java files outside the build path. It is not clear why editing a Java file which is inside a Java project but not on its build path works different from a *.java file in a simple project: for example the Outline view updates for all *.java files inside a Java project but it does not when the same file is in a simple project. Couldn't Java Core drop the test for the Java nature and behave like for files that are inside a Java project but not on its build path? Note: we released a workaround so that at least save no longer fails.
NOTE: workaround released for CompilationUnitDocumentProvider and CompilationUnitDocumentProvider2.
From the JavaModel standpoint, it makes quite a difference. When rooted inside a Java project, you can still access quite some properties such as classpath. When outside, you have no existency at all in the model. No way you can find a classpath (to resolve or whatever). This is why it is fairly fatal, however it should still preserve minimal functionalities like opening the editor and saving its contents.
I also observed that past the first error dialog (on win2000), I was able to edit/save the file further without any problems.
Actually, when adding methods, it fails again. Seems connected to reconciliation failures.
Support for shared working copies was getting in the way. Fixed in latest.
Fixed
Regression test added: WorkingCopyNotInClasspathTests#testReconcileAndCommit2
This worked for a week but since today, USE_WORKING_COPY_OWNERS is true in the Java UI plug-in it no longer works. Also, *.java files in a Java project but not on the build path are now broken i.e. can no longer be saved. USE_WORKING_COPY_OWNERS does the following: if (USE_WORKING_COPY_OWNERS) DefaultWorkingCopyOwner.PRIMARY.factory= getBufferFactory(); And when saving: if (JavaPlugin.USE_WORKING_COPY_OWNERS) { info.fCopy.commitWorkingCopy(overwrite, monitor); } else { info.fCopy.commit(overwrite, monitor); // next call required as commiting working copies changed to no longer walk through the right buffer saveDocumentContent(monitor, element, ignore, overwrite); } Added Martin to the cc-list. NOTE: You cannot reproduce the problem since we left the patch (see bug 43344) in. Simply disable the corresponding code in CompilationUnitDocumentProvider2.saveDocument(IProgressMonitor, Object, IDocument, boolean)
This is a slightly distinct problem now. No exception occurs, but the working copy commit seems a noop. Note that old code was manually force a document save independantly from the commit operation. Will investigate.
Closing, the problem lies on the UI side. After the commit operation, the resource got updated correctly, but the editor fails to notice this and persists in showing the dirty indicator. If switching to a different window and returning to editor window, then it will prompt to reload the file change. Entering separate UI defect, see bug 43879.
Verified.
