Summary: | Package content disapear in package explorer | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Benno Baumgartner <benno.baumgartner> | ||||||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | major | ||||||||||
Priority: | P3 | CC: | daniel_megert, markus.kell.r, tobias_widmer | ||||||||
Version: | 3.2 | ||||||||||
Target Milestone: | 3.2 RC3 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Benno Baumgartner
2006-04-26 04:34:41 EDT
Even worse: Given: P01 -> src -> a -> K1.java -> a.b -> K2.java 1. Right click on 'a' 2. Select 'Build Path->Exclude' 3. Right click on 'a' 4. Select 'Build Path->Include' Is: package 'a' with 'K1.java' is gone Close and reopen project->'a' is back A 3.2 candidate? Can you check if that's a regression compared to 3.1.2? If yes, please investigate a fix. It's a regression to 3.1.2. Minimal test case: Given java project P01: P01 -> pack -> E.java Exclude and then include 'pack' from/to build path. 'pack' is rendered as an empty package. Looks like a core bug. I could track it down to org.eclipse.jdt.internal.core.PackageFragment.getCompilationUnits() which returns an empty list for 'pack'. Move it to core for comment. Problem comes from the fact that refactoring's checks is the selection is available and it calls IPackageFragment#isStructureKnown() on a package fragment outside the classpath when the package is being excluded. We don't protect ourselves against this scenario and populate the model with an empty package fragment. When the package is included again, it is already in the cache but it is empty. In 3.1, JDT Core had the same bug, but refactoring didn't call IPackageFragment#isStructureKnown() on a package fragment outside the classpath. (I believe that the structured selection's element returned an IFolder instead of the IPackageFragment). Is that a potential problem in UI land ? Created attachment 40303 [details]
Proposed patch and regression test
Fix consists in checking if the package is not excluded when building its structure.
+1 for 3.2RC3 Dani - pls cast your vote With this fix, the test case described in comment 4 produced: Java Model Exception: Java Model Status [pack [in src [in P3]] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:485) at org.eclipse.jdt.internal.core.PackageFragment.buildStructure(PackageFragment.java:72) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:229) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:505) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:249) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:235) at org.eclipse.jdt.internal.core.Openable.isStructureKnown(Openable.java:387) at org.eclipse.jdt.internal.corext.refactoring.Checks.isAvailable(Checks.java:747) at org.eclipse.jdt.internal.corext.refactoring.RefactoringAvailabilityTester.isRenameAvailable(RefactoringAvailabilityTester.java:993) at org.eclipse.jdt.internal.ui.refactoring.actions.RenameJavaElementAction.isRenameAvailable(RenameJavaElementAction.java:182) at org.eclipse.jdt.internal.ui.refactoring.actions.RenameJavaElementAction.canEnable(RenameJavaElementAction.java:85) at org.eclipse.jdt.internal.ui.refactoring.actions.RenameJavaElementAction.selectionChanged(RenameJavaElementAction.java:68) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchSelectionChanged(SelectionDispatchAction.java:255) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.selectionChanged(SelectionDispatchAction.java:250) at org.eclipse.jdt.ui.actions.RenameAction.selectionChanged(RenameAction.java:80) at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:162) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160) at org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:1970) at org.eclipse.jface.viewers.StructuredViewer.handleInvalidSelection(StructuredViewer.java:1086) at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.handleInvalidSelection(ProblemTreeViewer.java:206) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.handleInvalidSelection(PackageExplorerPart.java:384) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.preservingSelection(PackageExplorerPart.java:402) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1407) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider$3.run(PackageExplorerContentProvider.java:615) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider$7.run(PackageExplorerContentProvider.java:666) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3325) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:158) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:326) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:479) at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:265) at org.eclipse.ui.internal.progress.ProgressManager.run(ProgressManager.java:1107) at org.eclipse.jdt.internal.ui.wizards.buildpaths.newsourcepage.ExcludeFromBuildpathAction.run(ExcludeFromBuildpathAction.java:95) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) 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:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) I am not sure that we want this exception to be logged. Created attachment 40326 [details]
Improved patch and regression tests
This patch also ensures that exists() return false for an excluded package fragment, and thus it avoids the JavaModelException observed by Olivier.
This patch breaks one of the UI tests: PackagesViewContentProviderTests#testBug123424_1 > In 3.1, JDT Core had the same bug, but refactoring didn't call
> IPackageFragment#isStructureKnown() on a package fragment outside the
> classpath. (I believe that the structured selection's element returned an
> IFolder instead of the IPackageFragment). Is that a potential problem in UI
> land ?
Benno, can you look into why we have an IPackageFragment instead of an IFolder for the element excluded from classpath?
Created attachment 40335 [details]
Patch to fix JDU/UI test
I think this is a bug in our test case. I checked it in the browsing perspective (where the tested code is actually used), and showing the default package makes no sense in that scenario. I think you can release the fix and I will fix our test.
+1 for 3.2 RC3.
Both fixes (Core and UI) make sense. Approving for 3.2 RC3. Released JDT Core patch and regression tests Relased patch for JDT/UI test. Verified for 3.2RC3 using I20060504-1600. |