Community
Participate
Working Groups
I have a target platform based on an update site that is updated very frequently. I noticed, that the bundle pool in \.metadata\.plugins\org.eclipse.pde.core\.bundle_pool now contains more than 5000 bundles! That also seems to have an impact on Eclipse startup time. It would be nice to have at least some API to trigger a gc to remove no longer needed bundles. One idea would be to remove all older versions of the same bundle to have every bundle only one time. Maybe this can be also done automatically when changes to the target platform are made by the user.
Currently, the bundle pool is GC'd when a target definition is deleted from the preference page. Perhaps we need to do this at other times. If users only use target editors and avoid the preference page, GC will not happen.
Created attachment 166477 [details] Target definition I just tested deleting my target (using 3.5 SR2) and nothing happed in the bundle pool. My target looks like this (screenshot). Am I missing anything? Btw, what's the API to trigger the gc?
org.eclipse.pde.internal.core.target.TargetPlatformService.garbageCollect()
Note, there seems to be some issues with GC. I noticed the same issue reported by Stephan. I upgraded my target platform a few times to catch up with the Helios RC and final build. When opening any Eclipse launch configuration the plug-ins tab was showing close to 2000 bundles to pick from. However, my active target platform only showed ~350 on the "Content" tab when resolved. I only checked briefly but it looks like there were no additional bundles but only bundles in multiple versions (from the various RCs). I think the bundle pool is problematic in combination with launch configurations. The target platform editor does not show duplicate versions. It gives users the impression that only the most recent versions will be available. However, launch configurations seem to use *every* bundle available in the bundle pool. I tried to trigger a GC by creating a dummy target definition and removing it afterwards from the preference page. The progress view indicated a "Garbage Collection" job. But every Eclipse launch configuration still showed all the bundles (this time with red error markers). After restarting Eclipse the launch configurations now were down to a few (!) bundles. Unfortunately, a lot of bundles defined in the current active target definition were removed too. Thus, I had to open the target definition manually to have it correctly resolved again.
(In reply to comment #4) > I think the bundle pool is problematic in combination with launch > configurations. The target platform editor does not show duplicate versions. It > gives users the impression that only the most recent versions will be > available. However, launch configurations seem to use *every* bundle available > in the bundle pool. This is not a problem with the launch configuration. The launch configuration is just displaying everything in the PDE state. What is in the PDE state is determined by the target platform, however it does not read them target definition file directly. Instead the target platforms saves information in preferences and the PDE state reads those preferences. The problem here is that something is causing a problem in storing/reading the preferences correctly when the bundle pool is involved.
I found out that the target definition (or PDE state) seems to be somehow invalid or corrupted after each eclipse restart. This causes the problems in the launch configuration (too many bundles, bundles cannot be resolved although they are there, etc.) I wrote a little plugin to refresh the target platform state which I call after each restart. After doing that, everything works as expected. The plugin gets the current ITargetDefinition via the ITargetPlatformService and triggers a refresh using the LoadTargetDefinitionJob. Snippet: final ITargetPlatformService targetPlatformService = getTargetPlatformService(); if (targetPlatformService != null) { final ITargetHandle workspaceTargetHandle = targetPlatformService .getWorkspaceTargetHandle(); if (workspaceTargetHandle != null) { final ITargetDefinition targetDefinition = workspaceTargetHandle .getTargetDefinition(); LoadTargetDefinitionJob.load(targetDefinition ); } } I haven't testet Helios yet, maybe this works there out of the box.
Created attachment 177679 [details] Patch which adds a GC button to the preference page small patch which adds a GC button to the preference page
Note that this is likely taken care of in Bug 328928 and the consolidated patch in Bug 328929. Well at least the more explicit control over the GC.
This needs more investigation in 3.8 as some users have ended up with massive workspaces and are using the workaround (create a target definition and delete) to force a GC.
We have to frequently delete the bundle pool in our implementation. Would be nice to have a button in the target editor which allows this. I think this would also solve the original feature request.
I tried to clean the directory \.metadata\.plugins\org.eclipse.pde.core\.bundle_pool with the file explorer. After doing that my targetplatform definition consisting of Software Sites was complaining that it does not find the file in the bundlepool directory instead of loading it again from the Software Site.
Is there any progress on this? As described by others simply cleaning the directory might leads to problem with an unresolvable target then, we currently have the problem that an artifact was updated but has the same version (external dependency), if the target was once loaded it never downloads the file again on refresh.
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.
