| Summary: | [reorg] move CU should create non existing package | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Christof Marti <christof_marti> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | benno.baumgartner, martinae |
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Christof Marti
I guess we should rather fix move CU to create a package if it does not exist yet. Agree? (In reply to comment #1) > I guess we should rather fix move CU to create a package if it does not exist > yet. Agree? > Do you mean if the refactoring script is applied and the package does not exist we should create it? Agreed. But what if you i.e. move a field to a non existing CU? Mmmm, this is what happens: I20070814-1100 Java Model Exception: Java Model Status [ds.java [in org.eclipse.jdt.internal.ui.refactoring [in ui refactoring [in org.eclipse.jdt.ui]]] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:492) at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure(CompilationUnit.java:83) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:229) at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107) 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.Member.getNameRange(Member.java:311) at org.eclipse.jdt.internal.corext.refactoring.structure.ASTNodeSearchUtil.getNameNode(ASTNodeSearchUtil.java:212) at org.eclipse.jdt.internal.corext.refactoring.structure.ASTNodeSearchUtil.getAbstractTypeDeclarationNode(ASTNodeSearchUtil.java:169) at org.eclipse.jdt.internal.corext.refactoring.reorg.ReorgPolicyFactory$SubCuElementReorgPolicy.getDestinationNode(ReorgPolicyFactory.java:3575) at org.eclipse.jdt.internal.corext.refactoring.reorg.ReorgPolicyFactory$SubCuElementReorgPolicy.copyMemberToDestination(ReorgPolicyFactory.java:3520) at org.eclipse.jdt.internal.corext.refactoring.reorg.ReorgPolicyFactory$SubCuElementReorgPolicy.copyToDestination(ReorgPolicyFactory.java:3613) at org.eclipse.jdt.internal.corext.refactoring.reorg.ReorgPolicyFactory$MoveSubCuElementsPolicy.createChange(ReorgPolicyFactory.java:2073) at org.eclipse.jdt.internal.corext.refactoring.reorg.JavaMoveProcessor.createChange(JavaMoveProcessor.java:150) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.createChange(ProcessorBasedRefactoring.java:234) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:130) at org.eclipse.ltk.ui.refactoring.history.RefactoringHistoryWizard.createChange(RefactoringHistoryWizard.java:531) at org.eclipse.ltk.ui.refactoring.history.RefactoringHistoryWizard.access$4(RefactoringHistoryWizard.java:527) at org.eclipse.ltk.ui.refactoring.history.RefactoringHistoryWizard$7.run(RefactoringHistoryWizard.java:832) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) Re comment 1: I agree, my concern is that the script did not apply. 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. If you have further information on the current state of the bug, please add it. 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. |