Community
Participate
Working Groups
Created attachment 156787 [details] Screenshot showing the error dialog Build ID: I20091210-1301 (Eclipse 3.6m4) on WinXP In my Workspace, I have two closed projects which I cannot delete any more: When I try to delete the project, no matter whether I choose to delete the underlying filestore, I get a dialog (see also attached): Delete Resources A fatal error occurred while performing the refactoring Found problems: No input element provided No context information available [back] [cancel] As an end user, I am confused by this dialog because it talks about a refactoring (which I did not initiate, I wanted to delete a project!). It also gives me no indication how to resolve the problem. I investigated the issue a little, and found that in the case of these two closed projects, the underlying location is displayed as <resource does not exist> in the project properties. I tried deliberately reproducing this case but could not; this state might have been initiated through my team provider (ClearCase Remote Client v7.1 Eclipse plugin), but I am not sure. The workspace was carried over from several older Eclipse versions. I can provide more data if needed. Expected behavior: ------------------ Deleting a project without the "Delete file system resources" switched on only unregisters the project from my workspace. This should always succeed regardless of whether the unerlying location exists or not. Furthermore, in case "delete file system" was chosen and the operation fails, the error dialog should be improved to not talk about a "refactoring" which is confusing for end users. I'm marking the issue as "major" since there is no workaround for getting rid of the stale project.
Martin, I've just tried to reproduce it on my I20100115-1100. The steps were: 1. Create a project 2. Close the project 3. Delete the project directory in the file system 4. Then I tried to delete the project and it worked You could add a test to our automated tests suite. This would help if the problem is intermittent.
Martin, what view are you using to delete the project? I'm guessing Package Explorer due to the refactoring message. Do you get the same problem in the Navigator or Project Explorer?
Yes, this is in the package explorer. In project explorer or navigator, I do not even see those strange projects, so the problem does not occur in those views.
(In reply to comment #3) > In project explorer or navigator, I do not even see those strange projects, so > the problem does not occur in those views. Hm, that is very strange. This suggests to me the projects don't actually exist in the resource tree but somehow the Java model or the view itself may be in a weird state. AFAIK the Navigator view will show all projects in the workspace. Do the weird projects still exist after a shutdown and restart?
Yes, they survived tons of restarts so far...
I happened to have the Coretools installed, and in the Metadata spy for my workspace, the projects do not show up either. I guess they are in fact no resources but in the JDT model only. Reassigning to JDT and reducing severity since this seems to be a really unusual case...
Now I remember that I and Tomasz experienced problems with closed projects in Package Explorer. One of them is bug 296786. Another issue I could see is that when a project was closed, it appeared in Package Explorer twice. I could delete one entry, however couldn't delete or open another one. Since it happened once or twice and I didn't have steps, I didn't raise a bug for it. Tomasz did it, however it is marked WORKSFORME now. I could not see those problems in Project Explorer.
I could not reproduce.
Perhaps this traceback, which I just found twice in my error log, is related to the problem: org.eclipse.core.runtime.CoreException: No property tester contributes a property org.eclipse.core.resources.projectNature to type class org.eclipse.jdt.internal.core.JavaProject at org.eclipse.core.internal.expressions.TypeExtensionManager.getProperty(TypeExtensionManager.java:123) at org.eclipse.core.internal.expressions.TestExpression.evaluate(TestExpression.java:96) at org.eclipse.core.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:53) at org.eclipse.core.internal.expressions.AndExpression.evaluate(AndExpression.java:29) at org.eclipse.ui.internal.dialogs.RegistryPageContributor.failsEnablement(RegistryPageContributor.java:260) at org.eclipse.ui.internal.dialogs.RegistryPageContributor.isApplicableTo(RegistryPageContributor.java:209) at org.eclipse.ui.internal.dialogs.PropertyPageContributorManager.getApplicableContributors(PropertyPageContributorManager.java:199) at org.eclipse.ui.dialogs.PropertyDialogAction.hasPropertyPagesFor(PropertyDialogAction.java:104) at org.eclipse.ui.dialogs.PropertyDialogAction.isApplicableForSelection(PropertyDialogAction.java:146) at org.eclipse.ui.dialogs.PropertyDialogAction.isApplicableForSelection(PropertyDialogAction.java:126) at org.eclipse.jdt.ui.actions.OpenViewActionGroup.fillContextMenu(OpenViewActionGroup.java:276) at org.eclipse.jdt.ui.actions.NavigateActionGroup.fillContextMenu(NavigateActionGroup.java:105) at org.eclipse.jdt.internal.ui.actions.CompositeActionGroup.fillContextMenu(CompositeActionGroup.java:72) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.fillContextMenu(PackageExplorerActionGroup.java:287) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.menuAboutToShow(PackageExplorerPart.java:780) at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:338) at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:469) at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:465) at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:491) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:235) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1050) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1074) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1055) at org.eclipse.swt.widgets.Control.WM_INITMENUPOPUP(Control.java:4277) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3980) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:348) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1594) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2032) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4678) at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method) at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:254) at org.eclipse.swt.widgets.Display.runPopups(Display.java:3972) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3518) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2407) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2371) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at com.windriver.ide.application.CopyOfIDEApplication.start(Unknown Source) at com.windriver.ide.application.UnifiedSWTSwingApplication.access$4(Unknown Source) at com.windriver.ide.application.UnifiedSWTSwingApplication.start(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:367) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566) at org.eclipse.equinox.launcher.Main.run(Main.java:1363) at org.eclipse.equinox.launcher.Main.main(Main.java:1339)
I'm not surprised that you cannot reproduce this -- I also do not know how my workspace got into this strange state. But the point I'm trying to make is: Once the workspace is in this strange state (there are items which are a JavaProject without an underlying IProject), Eclipse should allow me to get rid of these items. > Expected behavior: > ------------------ > Deleting a project without the "Delete file system resources" switched on only > unregisters the project from my workspace. This should always succeed > regardless of whether the unerlying location exists or not.
(In reply to comment #10) > But the point I'm trying to make is: Once the workspace is in this strange > state (there are items which are a JavaProject without an underlying IProject), > Eclipse should allow me to get rid of these items. I understand what you are trying to do. As long as we cannot reproduce this weird state, it is difficult to propose a solution. > > Expected behavior: > > ------------------ > > Deleting a project without the "Delete file system resources" switched on only > > unregisters the project from my workspace. This should always succeed > > regardless of whether the underlying location exists or not. I doubt this is the only reason why this failed. I tried to remove close projects for which I had removed the underlying location and it worked.
I think that this is actually a duplicate of bug 333437, which has exact steps to reproduce the problem. The "closed project" is not really a project, but it's a broken reference from a working set in "top level: working sets" mode. *** This bug has been marked as a duplicate of bug 333437 ***
The issue here is that the project does not actually exist, but it's shown in the Package Explorer, because it is in a Resource Working Set. The refactoring has no way to remove this project from the working set, since it only gets a reference to the inexistent project. The right fix is to make sure such invalid references are removed from the working set.
Reopening to fix in the ResourceWorkingSetUpdater.
Created attachment 186276 [details] Fix
Fixed in HEAD. The bad projects will not be shown in the working set any more. To manually resolve the problem in older builds, either - edit the working set (e.g. Package Explorer context menu > Properties) and remove the bad project), or - drag the project into the "Other Project" working set (that will remove it)
Created attachment 186277 [details] Team Project Set to reproduce the problem
(In reply to comment #16) The first workaround doesn't work, since the bad project ref doesn't appear in the working set Properties. > - drag the project into the "Other Project" working set (that will remove it) This works fine.
(In reply to comment #18) > The first workaround doesn't work, since the bad project ref doesn't appear in > the working set Properties. Yeah, sorry. But you can check/uncheck another project to cause a dummy change and then click OK. Probably the easiest solution: Open context menu on bad project(s), choose Assign Working Sets..., click Deselect All, OK.
*** Bug 311168 has been marked as a duplicate of this bug. ***
Verified for 3.7 M5 with I20110124-1800.
I happen to have exactly this issue with M2E Maven project and the same workaround. Shall I file a new issue?
> Shall I file a new issue? Yes. In general, don't reopen bugs that have been closed in a past milestone. > I happen to have exactly this issue with M2E Maven project and the same > workaround. Sounds like it's not exactly this issue, since this issue has been fixed. In the new bug, please add a screenshot and tell which working set type you use (right-click > Properties).
