Community
Participate
Working Groups
N20060426 With package explorer in flat layout 1. Create new java project with seperate src and output folders 2. create package p01 in src 3. create class Klazz in p01 4. Right click on p01 5. Select 'Build Path -> Use as source folder' 6. Right click on src/p01 7. Select 'Build Path -> Remove from bp' 8. Right click on p01 9. Select 'Build Path -> Include' Is: p01 is shown as empty package and has no + to expand it Should: It contains Klazz it should not be empty. The only way to access Klazz in the package explorer seams to be to close and reopen the project.
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 comment 0, comment 1 and comment 4 test cases using N20060504-0010 + JDT/Core v_663
Verified for 3.2RC3 using I20060504-1600.
