Community
Participate
Working Groups
Build Identifier: I20100513-1500 After changing the default association for rt.jar for my JRE from %JDK_HOME%\src.zip file to %JDK_HOME%\full-source\j2se folder, if I try to refresh more than one project, I see more than one task which says ####### "Refreshing external folders" (Blocked: The user operation is waiting for refresh to complete) Refreshing /.org.eclipse.jdt.core.external.folders/.link0 ######## Reproducible: Always Steps to Reproduce: 1.Extract the src.zip in %JDK_HOME%/full-source. 2. Window->Preferences->Java->Installed JREs->EDIT 3. rt.jar->SOURCE ATTACHMENT 4. EXTERNAL FOLDER->Change to a directory containing java full source distribution. 5. Select all the projects in the workspace. Press F5. BUG ( you could see more than one "Refreshing external folders" )
Hmm, looking at this it seems difficult to avoid to refresh the external folder for each project as the WrappedWorkbenchRefreshAction in the JDT/UI RefreshAction enumerates the list of selected projects and refreshes them one by one... Markus, any thoughts about this?
I don't see how the actual project refreshes could be combined. There's just IResource#refreshLocal(int, IProgressMonitor) to refresh a single resource, and if the selection contains multiple resources, they have to be refreshed sequentially. Furthermore, IResourceChangeEvent.PRE_REFRESH specifies that a separate event is sent for each project to be refreshed. I guess you somehow need to keep the RefreshJob you create in ExternalFoldersManager#refreshReferences(IProject[], IProgressMonitor) around and add more requests to the existing Job as they trickle in. But to be honest, I don't quite understand how the RefreshJobs are currently synchronized. From looking at the code, I guess they just run off and are only held up because all the folder.refreshLocal(..) need the external folders project's lock. You should maybe set the external folders project as scheduling rule of the RefreshJob and use IJobManager#find(Object) with a new (private) job family to find a waiting job to which you could add more folders to refresh. (These were just ideas, I've not tried to implement them nor deeply thought about them).
FUP of bug 302295 (this should have been added in the initial comment to give readers an easy click target...)
Created attachment 173228 [details] Proposed patch I have taken a similar approach as suggested by Markus. I have not used a private Job family, though, as it might affect the clients who are depending on the family type. To manipulate the paths, I have tried to improvise with a Vector as the need was a data model that is thread-safe, doesn't allow duplicates and ordered. Satyam, can you please review this patch and let me know?
Patch looks good to me -- I have only one minor comment to make. Methods are generally sorted and hence moving the newly added function accordingly will be good.
Released in R3_6_maintenance and HEAD.
Verified for 3.7M1 using build I20100802-1800
Change status to RESOLVED as this needs to be reverified for 3.6.1.
Verified for 3.6.1 RC2 using Build id: M20100825-0800
I am having this error message pop up every time I save a file in my workspace. I am using Eclipse 3.6.1 and the Android DDMS Plugin 0.9.9. I'd like to know when this fix will be made available to the public since it's quite annoying to have to work like this.
(In reply to comment #10) > I am having this error message pop up every time I save a file in my workspace. > I am using Eclipse 3.6.1 and the Android DDMS Plugin 0.9.9. I'd like to know > when this fix will be made available to the public since it's quite annoying to > have to work like this. You will have to wait for 3.6.2 or pick up one of the recent developer builds.
(In reply to comment #11) > You will have to wait for 3.6.2 or pick up one of the recent developer builds. No, this bug has the target milestone set to 3.6.1 and I verified that the patch has been released for 3.6.1, so this bug should already be fixed. Neal, if you can reproduce this problem in 3.6.1 without the Android DDMS plug-in, please file a new bug for JDT Core and mention this bug. Otherwise, please file a bug against the Android DDMS plug-in.
*** Bug 270201 has been marked as a duplicate of this bug. ***
