Community
Participate
Working Groups
To reproduce: 1. create Java project 2. Add external class folder that is outside the workspace 3. Add or remove a non-source file to the folder from the filesystem (eg- using windows explorer or mac finder) 4. Select folder in package explorer. Right-click -> Refresh 5. nothing happens and external class folder is still empty 6. Now, select the java project right-click -> refresh 7. Finally, class folder is refreshed and new files appear I would have expected that the refresh works on the class folder itself.
I tried this on Eclipse 4.2 M5 (I guess that would be JDT 3.8 M5). I have not tried on other versions.
Whenever you do operations in a filesystem on a file that's not active in the editor, a refresh is needed to show it in package explorer. The other way of doing this would be to simply copy the file in the windows explorer, then click on the folder in package explorer view, and press CTRL+V. The file will be copied into the folder inside Eclipse as well. I think this is expected behavior and not a bug
I do not think this is expected behavior. There is a "refresh" menu item on external class folders as well as a refresh menu item on the files themselves. However, these refresh menu items do not work. What I am trying to do is a bit more involved than just having the UI available for refreshes of external folders. But, that was the easiest way of describing and reproducing my actual problem. I am trying to allow my plugin to monitor a folder that is attached to a project as an external class folder. However, when I call IFolder.refreshLocal(DEPTH_INFINITE, monitor) on the folder, nothing happens and the folder is not refreshed.
Looks to be a duplicate of bug 357450.
On the face of it, I am not sure. Bug 357450 describes an issue where a file appears in a non-external class folder, but not in the folder itself in the workspace. This bug describes an issue where new files do not appear in an external class folder even after a refresh. It may be that the underlying problem is the same for both of these bugs, but the problem being described is different. So, whereas likely related to each other, I do not believe that they are duplicates.
Mostly looks like the same issue. Will be considered during investigation of bug 357450. *** This bug has been marked as a duplicate of bug 357450 ***
As per Bug 357450 c7, I am re-opening this bug. I believe this bug is related to Bug 305172 since both deal with the refreshing of external resources.
The DeltaProcessor does not get an event when "refresh" is called on external resources, including external archives. I am not sure if this can be addressed in JDT/UI or platform/resources has to be involved.
(In reply to comment #8) > The DeltaProcessor does not get an event when "refresh" is called on external > resources, including external archives. Mmmh, not true. Here's the stack trace: Thread [Worker-11] (Suspended (breakpoint at line 771 in DeltaProcessor)) DeltaProcessor.checkExternalArchiveChanges(IJavaElement[], boolean, IProgressMonitor) line: 771 DeltaProcessor.checkExternalArchiveChanges(IJavaElement[], IProgressMonitor) line: 764 JavaModel.refreshExternalArchives(IJavaElement[], IProgressMonitor) line: 271 BuildActionGroup$RefreshableViewRefreshAction(RefreshAction).refreshJavaElements(IStructuredSelection, IProgressMonitor) line: 218 BuildActionGroup$RefreshableViewRefreshAction(RefreshAction).performRefresh(IStructuredSelection, IProgressMonitor) line: 194 RefreshAction.access$0(RefreshAction, IStructuredSelection, IProgressMonitor) line: 188 RefreshAction$1.run(IProgressMonitor) line: 182
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
