Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 331300

Summary:	Provide more control over the target platform cache
Product:	[Eclipse Project] PDE	Reporter:	Martin Aeschlimann <martinae>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	major
Priority:	P3	CC:	curtis.windatt.public, jeffmcaffer
Version:	4.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Martin Aeschlimann

2010-11-29 03:49:04 EST

Build Identifier: Eclipse 3.6.1

Eclipse 3.6.1

We're using a target platform based on remote p2 repositories such as http://download.eclipse.org/releases/galileo.
When switching to that target platform, PDE will download the required plugins to a local folder.

For the developper it is not clear where this folder is (it turns out to be in the workspace), if it is shared, how it can be cleared ect. This makes it difficult to debug problems with it:
Many time ran into problems of with the target platform, where some plugins or features didn't seem to be loaded. The only way out of that was to create a new workspace and even a new Eclipse installation (as it seems that the cache folder was shared across workspaces!). This is all very time consuming and difficult to debug as the management of the bundle-pool is hidden.

Please provide functionality to configure that folder, see the content and to clear that folder to force a reload.

Reproducible: Couldn't Reproduce

Comment 1 Curtis Windatt

2010-11-29 10:41:51 EST

Ability to change the location of the bundle pool is enhancement/bug 282352.

Ability to view the information there and force GC or deletion is part of bug 329387.

I'm going to mark this as a dupe of the first bug.  I do not know whether we will be working on fixing it in 3.7.  Jeff is doing some work around targets and might be able to spend time on it.

*** This bug has been marked as a duplicate of bug 282352 ***

Comment 2 Jeff McAffer

2010-11-29 11:26:45 EST

IMHO this is more a dupe of bug 329387.  Martin is not particularly interested in the optimization proposed in bug 282352 so much as the control and visibility afforded by an advanced preference page.  Regardless, the requested work does fall under another pre-existing bug.

FWIW, from time to time I too have seen cases where the bundle pool *appeared* to be being shared between workspaces.  I've no idea how that was happening but it sure was frustrating.  With some of the more recent changes that I've contributed the situation should be better as PDE is now using its own p2 agent data area.  I think the problem was coming from information leaking from workspace to workspace through the IDE's agent and preferences.

As for sharing bundle pools, it would be cool and we may be able to do something but I currently do not have plans to do this for 3.7.  Recent changes allow one bundle pool to *copy* from another local bundle pool thus eliminating the need to re-download.  Still bloats the disk but disk is cheap :-) I'd be happy to help someone else that is interested in driving the sharing changes though...

Comment 3 Martin Aeschlimann

2010-11-30 01:01:17 EST

Thanks Jeff and Curtis for your comments!
Yes, bug 329387 covers this request well.
I've seen the bundle pool shared across workspaces two times already. I have no idea how the first workspace knew about the second workspace. Maybe it can happen when using 'Switch Workspace' to create the new workspace. Or my suspicion was it has to do with data in the Eclipse install.

Just a question: Can I manually (on the file system) delete the cached bundles, and will they be reloaded? Or will bring PDE in troubles?

Comment 4 Jeff McAffer

2010-11-30 09:17:52 EST

I think what is happening is there are two workspaces but one eclipse install.  PDE used to use the IDE p2 agent data area to manage the profiles that backed Software Site target provisioning.  This means that, for example, two workspaces having .target files of the same name would end up using the same profile.  The profile contains the location of the bundle pool so, voila, (unintended) sharing.

If my theory is correct, creating a new target (with a new name) should fix up the problem. Its either that or some cross fertilization.  Either way, I don't think that deleting the bundle pool would help.  Certainly you can try, it should not corrupt PDE (the pool will just be recreated)

You could also try with one of the more recent I builds to see if that addresses the problem. They should have the changes to use a separate p2 data area.