Summary: | Renamed file is not excluded from project build | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Askar Rahimberdiev <askar> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P1 | ||
Version: | 1.0 | ||
Target Milestone: | 2.0 M3 | ||
Hardware: | PC | ||
OS: | Windows NT | ||
See Also: | https://github.com/eclipse/xtext-lib/pull/16 | ||
Whiteboard: |
Description
Askar Rahimberdiev
2001-11-22 12:39:55 EST
Need to double check in 2.0 with new builder Kent - Please verify with new builder A.java & A.class are both removed when A.java is renamed. Note: You cannot rename the suffix of a .java file in the Java perspective, you have to use a Resource perspective... but then when you return the Java perspective the file A.java is still visible. 'Refresh from local' does not remove it from the list. There would be a model refresh problem... The following exception in the delta processor prevents the java model from being refreshed: java.lang.IllegalArgumentException: Missing message: convention.unit.notJavaName in: org.eclipse.jdt.internal.compiler.util.messages at org.eclipse.jdt.internal.core.CompilationUnit.<init> (CompilationUnit.java:41) at org.eclipse.jdt.internal.core.PackageFragment.getCompilationUnit (PackageFragment.java:161) at org.eclipse.jdt.internal.core.DeltaProcessor.createElement (DeltaProcessor.java:368) at org.eclipse.jdt.internal.core.DeltaProcessor.elementRemoved (DeltaProcessor.java:558) at org.eclipse.jdt.internal.core.DeltaProcessor.updateCurrentDeltaAndIndex (DeltaProcessor.java:809) at org.eclipse.jdt.internal.core.DeltaProcessor.traverseDelta (DeltaProcessor.java:880) at org.eclipse.jdt.internal.core.DeltaProcessor.traverseDelta (DeltaProcessor.java:943) at org.eclipse.jdt.internal.core.DeltaProcessor.traverseDelta (DeltaProcessor.java:943) at org.eclipse.jdt.internal.core.DeltaProcessor.processResourceDelta (DeltaProcessor.java:774) at org.eclipse.jdt.internal.core.JavaModelManager.resourceChanged (JavaModelManager.java:1103) at org.eclipse.core.internal.events.NotificationManager$1.run (NotificationManager.java:125) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:809) at org.eclipse.core.runtime.Platform.run(Platform.java:395) at org.eclipse.core.internal.events.NotificationManager.notify (NotificationManager.java:140) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges (NotificationManager.java:43) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges (NotificationManager.java:64) at org.eclipse.core.internal.resources.Workspace.broadcastChanges (Workspace.java:121) at org.eclipse.core.internal.resources.Workspace.endOperation (Workspace.java:709) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1237) at org.eclipse.ui.actions.WorkspaceModifyOperation.run (WorkspaceModifyOperation.java:78) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:98) When moving an element, we assumed that the new element type was the same as the old one. Fixed by always computing the new element type. GitHub Pull Request 16 created by [vorburger] https://github.com/eclipse/xtext-lib/pull/16 |