Community
Participate
Working Groups
3.2m6 Renaming a package updates contained compilation units but fails to update references in other packages. The trigger seems to be the fact that the project lives on a project based on a non local file system is triggering the problem. This is always reproducible on our filesystem.
Clarifying, the second sentence should read: "The trigger seems to be the fact that the project lives on a project based on a non local file system". Increasing severity as this strongly limits the usefulness of refactoring on products that use alternate EFS file systems.
>fails to update references in other packages. Does it fail with an error or does it just not do it? Anything in .log?
Is there a (free) non local file system that we could use to reproduce? Why do you think the problem is in the refactoring code and not in the file system implementation? Does a Java search for references to the package find the references?
There is a in memory file system implementation in the plugin org.eclipse.ui.examples.filesystem. However, I cannot reproduce the failure with the memory file system. Rafael, I created the following: Project1 src p1 A.java p2 B.java Where B.java is a subclass of A.java, and it contains a single type import statement. When I refactor->rename "p1" to "pnew", the reference in B.java is correctly updated. Does this case fail for you? If not, can you describe a case that fails?
Re: comment 2 - no errors logged, it just fails to update references in other packages Re: comment 3 - I am not sure yet, and I should have made that clear, the only thing I find suspicious is that no errors are logged, so the I/O operation seems to complete successfully. As you suspected, search will fail to find references in the cases I saw the problem. But testing this I noticed that contrary to what I said initially, the problem happens for some packages only (every time), not all of them. I don't understand yet what is the trigger. Re: comment 4 - John, one case I saw this happening was when having the org.eclipse.core.content plug-in imported as source into a project that lives in our file system implementation. Renaming the org.eclipse.core.internal.content package to org.eclipse.core.internal.content2 did not update references from org.eclipse.core.content. Meanwhile, I will try to reproduce the problem in debug mode and see what is going on.
John, I could not make a test case that reproduced the problem, other than our own code base and the case in org.eclipse.core.content. Using import package.* instead of import package.type affects the results of my testing, in the cases I was able to reproduce the problem. It seems that having import package.* will cause the reference to be properly found. Will try to see if I can reproduce the problem with the in-memory filesystem and the content type project.
Rafael, this sounds like a broken search index for the affected file. Can you try to reproduce in a new workspace? If it works in another workspace, then it might be enough to rebuild the search index.
I cannot reproduce it with the wrapper file system from org.eclipse.core.tests.resources, which is similar to ours. That would indicate that the problem is indeed in our EFS file system implementation. Feel free to close as user error.
Thanks for the feedback
Ok, I ended up taking the wrong track while investigating this, but now I think I understand the problem. ResourceCompilationUnit will take the file location URI scheme specific part as the compilation unit file name. In my case, the URI has a query as well, it looks like this: protocol:/org.eclipse.core.contenttype/src/org/eclipse/core/internal/content/Activator.java?file:/D:/dev/runtime-New_configuration So the compilation unit in this case will be /path/?query. For instance: /org.eclipse.core.contenttype/src/org/eclipse/core/internal/content/Activator.java?file:/D:/dev/runtime-New_configuration URI.getPath() returns the path only, shouldn't that be used as the compilation unit name instead? Search will use the bogus compilation unit name later on in PackageReferenceLocator#isDeclaringPackageFragment() and will get confused by the query part.
Given EFS is new to 3.2, we want to address it in maintenance release. I don't think it is a stop ship issue for 3.2.0 at this stage in the game.
Agree this is not critical for 3.2. The CompilationUnit class later assumes that the "fileName" field refers to the local file system in the getContents method, so this would be non-trivial to fix.
getContents() is actually overriden in ResourceCompilationUnit. CompilationUnit is used by the batch compiler only, so the assumption is ok.
Created attachment 44920 [details] Thanks Rafael. Here is the corresponding fix.
Fix released for 3.3 M1 in HEAD and released for 3.2.1 in TARGET_321 branch.
Verified for 3.3 M1 using build I20060807-0010.
Verified for 3.2.1 using build M20060908-1655
