Community
Participate
Working Groups
Build Identifier: 20100917-0705 Repeated in "Steps to Reproduce" since this is mainly a procedural description. 1. Create 3 Java Projects in the same workspace 2. Add two good compiled Java files in 2 of the projects 3. Create links to the two Java files in the 3rd project 4. Remove one of the original Java files (may have to restart somewhere to the effect below but I did not) 5. Notice red "x" in linked project (3) with "cannot find ....java file" Problem message. 6. Go to linked project (3) and try to remove the link to the missing target file. Cannot be done. 7. Should not have to do the following, I should not have to try this! 7a. Shutdown Eclipse 7b. Open .project file for linked project (3) 7c. Remove the offending <link>...</link> block. Can try a restart here but does not work. 7d. Clear the associated "bin" directory. 8. Restart Eclipse, unfortunately, Eclipse puts the <link>...</link> block back in. I am not sure if it does it every time but it did for me if I did not clear the "bin" directory and sometimes even if it was cleared. 9. If red "x" still appears, try Project clear, did not work for me. 10. Problem usually persists but some times the above works. Editorial: One should be able to delete a link that points to a missing file; that is, Eclipse should remove the associated .class file in the link Project "bin" directory and just remove the link. If other Projects, say a fourth project, depend upon the linked version of the missing file, those dependencies should not stop the removal. One should just get a bunch of red "x"s with "cannot resolve reference" messages. Reproducible: Always Steps to Reproduce: See details section, repeated here since this is mainly a procedural description.. 1. Create 3 Java Projects in the same workspace 2. Add two good compiled Java files in 2 of the projects 3. Create links to the two Java files in the 3rd project 4. Remove one of the original Java files (may have to restart somewhere to the effect below but I did not) 5. Notice red "x" in linked project (3) with "cannot find ....java file" Problem message. 6. Go to linked project (3) and try to remove the link to the missing target file. Cannot be done. 7. Should not have to do the following, I should not have to try this! 7a. Shutdown Eclipse 7b. Open .project file for linked project (3) 7c. Remove the offending <link>...</link> block. Can try a restart here but does not work. 7d. Clear the associated "bin" directory. 8. Restart Eclipse, unfortunately, Eclipse puts the <link>...</link> block back in. I am not sure if it does it every time but it did for me if I did not clear the "bin" directory and sometimes even if it was cleared. 9. If red "x" still appears, try Project clear, did not work for me. 10. Problem usually persists but some times the above works. Editorial: One should be able to delete a link that points to a missing file; that is, Eclipse should remove the associated .class file in the link Project "bin" directory and just remove the link; <link>...</link> block. If other Projects, say a fourth project, depend upon the linked version of the missing file, those dependencies should not stop the removal. One should just get a bunch of red "x"s with "cannot resolve reference" messages.
I tried this with 3.7M6 (I20110310-1119) and can't reproduce. I mean, after deleting the (original) java file from the referenced project, I am able to delete the link from the corresponding referencing project. Another observation I made is, there is only a warning sign (along with the error message, of course) when the original file is deleted. Can you please check with the latest build?
Closing the bug. Should it occur even with the latest build, please reopen.
I am able to reproduce the problem with I20110421-1800 I get the following error in my error log: ########### !SUBENTRY 1 org.eclipse.jdt.core 4 969 2011-04-25 16:30:51.117 !MESSAGE File not found: C:\Work\wokspaces\testworkspace\Project1\src\pkg\Test1.java. !STACK 1 org.eclipse.core.runtime.CoreException: File not found: C:\Work\wokspaces\testworkspace\Project1\src\pkg\Test1.java. at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:55) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:371) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:773) at org.eclipse.core.internal.resources.File.getContents(File.java:289) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1186) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1160) at org.eclipse.jdt.internal.core.CompilationUnit.openBuffer(CompilationUnit.java:1154) at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:116) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:258) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:518) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:255) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:241) at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:196) at org.eclipse.jdt.internal.core.JavaElement.getChildrenOfType(JavaElement.java:210) at org.eclipse.jdt.internal.core.CompilationUnit.getTypes(CompilationUnit.java:920) at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaDeleteProcessor.willHaveAllTopLevelTypesDeleted(JavaDeleteProcessor.java:815) at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaDeleteProcessor.getCusToEmpty(JavaDeleteProcessor.java:807) at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaDeleteProcessor.addEmptyCusToDelete(JavaDeleteProcessor.java:798) at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaDeleteProcessor.recalculateElementsToDelete(JavaDeleteProcessor.java:362) at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaDeleteProcessor.checkFinalConditions(JavaDeleteProcessor.java:263) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:224) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:209) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2310) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: java.io.FileNotFoundException: C:\Work\wokspaces\testworkspace\Project1\src\pkg\Test1.java (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(Unknown Source) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:362) #############
Under investigation. Target will be set when the problem is identified.
Considering this for M4.
Since Jay had to go on unavoidable unplanned time off for several days, this is not ready: retargetting to 3.8 M5.
Looks like we can't have a complete fix in JDT/Core for this. The fix has to go to JDT/UI. In my investigation I found that the fix may have to be made to JavaDeleteProcessor and probably to DeleteModifications. It makes sense we let the Core code to throw the exception in case the linked resource is not available and let the UI handle the exception. Moving to UI for further investigation.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
