Community
Participate
Working Groups
I have a target platform with following site with two locations: * https://download.eclipse.org/releases/2019 * Internal upadte site only hosting some plugins (using package drone) Every location is configured with includeMode="slicer". Resolving the target platform takes very long (I am waiting now for about half an hour since lates restart). While resolving it seems like it downloads absolutly unrelated sites like eclipse.svnkit.com (I do not know when I last used svn): Resolving Target Contents....: Fetching site.xml from http://eclipse.svnkit.com/1.8.x/ I already disabled EVERY update site in my managed sites even I do not know why resolving a target platform should consider my configured update sites outside of the target definition. Other colleagues do not have these problems with resolving the same target platform (but some have others).
Seems like it is anything within the workspace. I just created a new workspace and imported some of the projects with one of the target platform files. Here the same target platform resolves very quickly (less than one minute).
I switched back to my old workspace and only removed .metadata/.plugins/org.eclipse.pde.core. Afterwards the target plaform resolved still very quickly. I tried again to grep (even zgrep) every file in this directory to get any of the suspicious URLs but I didn't found any further hint.
By going through folder by folder, always renaming one and rename it back I finally found the file which seems to causes the problem: when I remove .metadata/.plugins/org.eclipse.pde.core/.p2/org.eclipse.equinox.p2.engine/.settings/org.eclipse.equinox.p2.artifact.repository.prefs it is fixed. Looking into the file there seems to be a lot of properties which referencing target platform definitions or repitories (?) ... a lot of stuff I used long time ago. I have absolutely no idea why eclipse must try to connect all these locations. The suspicious URLs are also listed but with escaped : that's why I did not found it.
Thank you so much Corneliud! I had enough of this and was going to write a bug but I found this bug and workaround solution! My prefs file contained 600 uri's which were all being contacted, when only 16 of those really needed to be contacted for my specific target. Is this not a bug? Caching stuff is supposed to make things faster, not slower! It was a running joke in my team how long it takes to load a target... until today!
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. If you have further information on the current state of the bug, please add it. 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.
