Community
Participate
Working Groups
Although JDT Weaving has solved many kinds of refactoring problems with Aspect elements, there are still quite a few things that do not work, or produce incorrect behavior. This bug is here to track all the refactoring problems.
1. When moving to a new package, imports are not updated for other aspects and for target types of ITDs. 2. When doing drag and drop to a new package, the original is not removed 3. When doing copy and paste into the same package, the top level type in the new AJCU still has the old name.
Seems that #2 is a JDT problem. See Bug 259328.
OK. Fixed #1. Seems that there was an escape hatch put in AJCompilationUnit.java inn the getAllTypes() method. This method signals that the AJCU has no types if the method is being called from within a refactoring context. Now with JDT Weaving enabled, this escape hatch can be closed.
Fixed #3. Seems that the getPrimaryType() Method for AJCompilationUnits was always returning null. This is because the assumption is that the primary type is a SourceType (aka Java type). Now, I check to see if the aspect type exists first, and if so return that, otherwise, try to return a source type. See AJCompilationUnit.getType().
I shouldn't get too happy here about fixing refactoring because there still seems to be lots of problems when the AJCU is more complicated. Seems that the drag and drop of a more complicated aspect can cause a class cast exception. Here is what I think is going on: 1. The aspect has a declare declaration as well as a reference to a type that will need to be added to the import statements. 2. When determining what needs to change for the refactor, a sort of compilation occurs. During this compilation, declare declarations are converted into field declarations. 3. Because "declare" is not a real type, the compilation fails with a missing type binding for the declare. What we need to do is ensure that in this instance, declare declarations are ignored.
OK. Able to fix that by making a small change to AspectsConvertingParser such that "declare" keywords are converted to "int" for use in situations where the IDE is looking for references.
Looks like this might be the place to report this. Are we expecting simple refactor-rename of the member name for an ITD method to work? Running refactor-rename against 'id' here: void Target.id(int i) {} causes: ('Type name cannot contain a '.') because it considers Target.id to be the name when I am just renaming the member name. This impacts Roo usage. I would also hope callers of the ITD get updated, but of course I can't test that out as I can't rename.
This is not working because rename refactor for Java elements sends a java parser down the target file to look for the element to be renamed. This obviously fails because the ITD is not using Java syntax. What is the behavior when you try to rename the ITD from a different file (ie- where it is referenced instead of being declared)? We may need to create a new refactoring participant to get the latter to work, and we may need to create a special ITD Rename Refactoring to get the former to work.
When attempting to rename where it is used it lets me type something in but when I press return to execute the rename it reverts to the original name immediately
OK. Looking into this more now. Probably won't implement this immediately, but here is what I think needs to happen to get rename refactoring of ITDs working: 1. before advice on RenameSupport.create(RenameJavaElementDescriptor) 2. in this advice, set the descriptor's fRefactoringId to be something like 'org.eclipse.ajdt.ui.rename.itd' 3. create a new refactoring contribution by extending the associated extension point The above ensures that our rename refactoring is instantiated instead of erroneously instantiating a JDT refactoring. (Maybe we want separate refactoring contributions for each of ITD fields, methods, and constructors.) After that, we need to figure out how to implement the refactoring itself, and we will likely have to copy significant code from the jdt side. I think that would be sufficient. In the short term, we should probably create a nice warning message saying that this is not implemented yet, rather than have Eclipse throw a class case exception.
Try to solve for 2.1.0.
Determining what will be tackled for 2.1.1 release.
Rename refactoring is now known to work in all the situations described in this bug. All tests are passing locally.
