Community
Participate
Working Groups
Created attachment 85591 [details] The project .classpath file Build ID: M20071205-0800 Steps To Reproduce: 1. Aspect file (.aj ext) exists in one package 2. Context click in project explorer and select move refactoring 3. Select destination package 4. Dialog pops up informing of problem - non related xml file opened in editor disappears and is later found to be deleted. Additional files (all were non source i.e. neither .java or .aj) were found to have been deleted. More information: Aspect was moved to target package even though the exceptions were thrown in the refactoring. Additionally, a name refactoring for the same file failed just before this operation when the file was opened in an editor - the refactoring was initiated in the project explorer by context clicking the .java file child in the tree (there is a child with an .aj extension as well, not sure if this is normal). The result of the name change refactoring left the file with a changed name, but with the old name as the aspect name inside the file. The reason I'm mentioning the name change refactoring is that it might be related to the failed move refactoring. The build is controlled by Eclipse and Maven 2 - I have Maven integration through the m2eclipse plugin. Eclipse is set up to build to the same target directories as Maven. The files that were deleted are specified in the .classpath file in a nonstandard way in terms of source and output directories. The reason is that when Maven builds, there is some token expansion, so it doesn't make sense for Eclipse to automatically copy these to the output without this expansion so these source directories are mapped to themselves as the output. This necessitates a Maven build before everything is available in the output location, but this is a minor annoyance compared to the benefit of being able to use Eclipse and Maven in parallel. We haven't really had any issues with the build so far. This deletion of non source files has also happened with another co-worker when she added aspect support to the same project (my changes to add this nature to the project are local as I was afraid of committing with this possible freak occurrence). Interestingly, I don't see anything in the log related to this refactoring, but I do see one exception due to one of the files (mockApplicationBeanRef.xml) being missing after the deletion happened. I will include the complete log file as an attachment. eclipse.buildId=M20071205-0800 java.version=1.6.0_03 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_CA Framework arguments: -showlocation Command-line arguments: -os win32 -ws win32 -arch x86 -clean -showlocation This is a continuation of log file C:\dev\eclipse-workspace-general\.metadata\.bak_0.log Created Time: 2007-12-18 23:28:02.248
Created attachment 85592 [details] The project file
Created attachment 85593 [details] The Maven 2 pom file
Created attachment 85594 [details] The Eclipse log file
Thanks for the detailed information on this bug. I will look into this after 1.6.0 comes out. I think it is related to bug 151067. (Not necessarily duplicate, though.
There seems to be 2 issues here. First, I think the problem is that JDT has changed the way it processes resource rename refactoring. In the past resource rename refactorings used the same factory class as compilation unit rename refactorings. Now it is created in a different manner. So, when we ask the old factory to create a rename resource refactoring, it returns null. The second problem is that AJDT is using the rename *resource* refactoring instead of the rename *compilation unit* refactoring. So, even if it did refactor properly, the Aspect would still have the old name. When I change the action to use the proper kind of refactoring, still doesn't work. The reason is that there is a call to org.eclipse.jdt.internal.corext.refactoring.Checks.checkIfCuBroken(IMember) gets the underlying resource and asks JavaCore to create an ICompilationUnit for it. This creates a CompilationUnit, not an AJCompilationUnit. And hence the unit thinks there are syntax errors and the refactoring cannot proceed. When I get jdt weaving to work, this problem should go away as long as the proper Compilation unit refactoring is being used.
Created attachment 114961 [details] when jdt weaving is applied, this patch will enable proper compilation unit rename refactoring for aj files This patch on its own will not enable rename refactoring for compilation units, but will turn it on once jdt weaving is in place.
patch from comment 6 is in.
This problem is now fixed with JDT weaving enabled
