Community
Participate
Working Groups
currently the target management code uses the global p2 agent to manage repos. This is convenient but may end up affecting the tooling installs. For example, someone adds a repo with later content to their target world and their tools thing there is an update. The code is reasonably factored such that it should not be too hard to have PDE use its own p2 Agent. the user flow would be affected in that they would not share the repo lists. That could be good or bad.
I have experimented with using our own agent in PDE. For most use cases, it was an easy change. However, I remember there being a few issues with the UI we reuse from p2.
Good to know. I can help work through them if you like (though I am not a p2 UI expert). It would likely be beneficial for p2 as well. Not to rush it but finding the problems sooner rather than later will improve the chances of getting them addressed for Indigo. Let me know if/how I can help.
From bug 328929: One thing I did notice is that the p2 GC potentially runs at the end of every provisioning operation. That means that as you click around in the target editor and add/remove things from your list of features in a site, the GC is merrily running and removing things. The net effect is that you have to redownload them. grrrr. We can control the GC but since we're using the global p2 agent, turning it off (for example) turns it off for everyone. Another reason to use have a PDE p2 Agent.
Created attachment 182061 [details] patch to use a unique p2 agent This is a first cut patch at having PDE use its own p2 agent. On talking to Curtis we also decided to consolidate all the p2 related target stuff in one place, P2TargetUtils. This is a set of static helper methods for getting the various p2 services as well as controlling where/how p2 bits are laid out. Basically a consolidation of code from TargetPlatformService, AbstractTargetHandle and elsewhere. Turned out reasonably well. I've done some rudimentary testing to see that things still work but nothing exhaustive. This patch does NOT include changes to GC triggering behaviour. It does however modify somewhat the gc calling code to call gc on every target profile when invoked. We should really simply stop the PDE p2 GC service permanently and then just call it explicitly. That would be easy enough to put in P2TargetUtils.getGarbageCollector().
A slightly updated version of this patch has been consolidated with several other overlapping patches and attached to bug 328929. discussion of issues related to this enhancement should continue here. The consolidated patch is just to ease application.
Just starting to look at the target patches, but I saw that there is now a clean-up button on the preference page. Why is this necessary? I would prefer to have everything GC automatically over forcing the user to deal with it. Not to mention it requires a deep knowledge of the target internals to know why pressing the button is necessary.
The cleanup button is not 100% required and I agree it does imply some complexity. Note that we don't need to tell folks what they are cleaning up. It is pretty much assumed that PDE is caching stuff somewhere so Cleanup cleans up that cache. The thinking was that figuring out when in the user's workflow it makes sense to GC is hard. Currently the only automatic point is when you remove a profile. That's a bit obscure and infrequent. (I don't think I've ever removed a target using the prefs page). Also, for people who are frequently updating their targets, that's not frequent enough. Perhaps GC on update makes sense. I'm not sure. The consequences of getting the timing wrong are pretty significant if your target is large/network slow/disconnected. The flipside of doing it infrequently is that there is some disk bloat. If someone notices they can click the Cleanup button. FWIW, Maven uses a manual flush for their local repos. Yes, they get slammed for disk bloat. They also get slammed for download delays. Cant win.
(In reply to comment #7) > FWIW, Maven uses a manual flush for their local repos. Yes, they get slammed > for disk bloat. They also get slammed for download delays. Cant win. In the past I noticed that the clean-up did not trigger correctly. For example, when updating targets the launch configurations and manifest/feature editors still showed a lot old bundles from the pool. Thus, a manual flush would be helpful in such a case. However, I also had issues with a manual flush. It removed too many bundles so that I had to manually re-load the target platform. In general, I think a user should to be aware of the bundle cache and advanced users should have an option to perform manual cache maintenance.
Fixed in HEAD. Thanks for all the great work Jeff!
Only issue found is the possibility of a stack overflow (bug 332138) which is fixed for M4. Marking this as VERIFIED.
