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

Bug 211346

Summary:	[ui][GC] UI prefs for artifact GC
Product:	[Eclipse Project] Equinox	Reporter:	Susan McCourt <susan>
Component:	p2	Assignee:	P2 Inbox <equinox.p2-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	Allan_Godding, john.arthorne, pascal
Version:	3.4
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	212078
Bug Blocks:

Description Susan McCourt

2007-11-28 17:59:28 EST

Some preference UI appeared in the SDK UI for the artifact gc, but there were no preference constants/initializers added that matched it.

I did the following:
- I cleaned up the wording to avoid words like "artifacts" and such - these don't appear in the end user UI anywhere
- I moved the pref controls to the general updates pref page rather than the auto update page
- I created constants/initializers for the values

When I went to hook it up, I see that the GCActivator checks its own prefs.  I think that instead we want to have configurable values passed in to the GC activator, so that each RCP app, etc., can define the prefs any way they like.  It seems like what we need to pass into the activator is how long to keep the artifacts?  (There was a pref that implied this in the SDK UI changes from this morning).

I would assume that if GC is disabled I wouldn't even bother starting the GC plug-in, but once it is enabled, I would activate it when the user enabled it, or on startup, much like I do the update checker.

Some general questions:
- How do I find the GC?  should it be available as a service?  So that I look for it on startup and activate it if it is there?
- Does it handle a "keep for" period yet or for now is it still eager?

Do we want to hook this into the UI for M4?

Comment 1 Allan Godding

2007-11-30 11:51:14 EST

The reason that it appeared as though there were no preference constants/initializers that matched the GC preferences was because it was suggested that I create a preference store separate to that of the SDK UI's.  The constants can be found in org.eclipse.equinox.p2.garbagecollector.prefs.GCPreferenceConstants (there is currently only one constant in there).  This was put here to ensure that the GC plugin does not depend on the UI, but rather the UI depends on the GC.

I'm guessing that some of your confusion is coming from the fact that I had left a "gcRetentionTime" message in the SDK UI messages.properties.  I've been working on the retention policy stuff at the same time and I did my best to roll back those changes when we committed the initial GC code.  I apologize for not catching that one :).  To clarify, the GC has absolutely no working retention policies currently.  To answer your second question, it is still eager cleanup.  My intention for the initial check-in was to only have the enable/disable checkbox on the preference page.

As for your first question, I'm hoping Pascal and I can address that by having the exemplarysetup start the GC bundle.  After startup there shouldn't be any need to find the GC, it should just run self-sufficiently.

Comment 2 Susan McCourt

2007-11-30 13:12:39 EST

I have some verbage in the pref page that implies a retention time, and I'll remove that for M4.

Question (sorry, I haven't really looked at your implementation at all)...
Is the GC working on all artifact repos in the system?
Will it ever be shared by multiple apps?

What I'm getting at, is does it make sense the for the GC itself to have prefs?  I was thinking that the GC wouldn't have prefs per se at all.  It would just have API for enabling/disabling, etc...and then different apps could present prefs (or not) their own way, and call some API that makes the right thing happen.

Comment 3 Pascal Rapicault

2007-12-01 15:27:58 EST

The preference talking about activation is just a temporary thing to allow for turning the gc off if it breaks us. If you want to get rid of it you can since the gc can be turned off by simply stopping the bundle.

As for the final goal, the GC needs to be able to retain its settings across sessions. The scope of these settings is unlikely to be the application but probably the profile. Then how these settings are shown to the user and set is likely to be dependent on the application.
For the SDK we may want to show we are cool by allowing some low level control such as an expiry date when we get it.

Comment 4 Susan McCourt

2007-12-07 14:07:25 EST

investigate for M5

Comment 5 Susan McCourt

2008-01-23 14:41:58 EST

marking 3.4 as this is not critical for M5.

Comment 6 Susan McCourt

2008-03-03 19:44:31 EST

Are we happy with the default artifact GC behavior or do we want to add prefs for this in 3.4?

Comment 7 Pascal Rapicault

2008-03-03 19:55:23 EST

A UI becomes really necessary if we have GC policies (e.g. time based policy). Until that I would be tempted to not have any UI at all.

Comment 8 Susan McCourt

2008-03-03 19:56:23 EST

removing milestone.  I'll revisit this bug if/when timed retention policies are added.

Comment 9 Susan McCourt

2009-07-09 17:07:57 EDT

bulk update:  UI bugs not yet assigned a milestone are returned to the inbox.

Comment 10 Pascal Rapicault

2009-09-02 11:35:29 EDT

GC is too much of an implementation details. I don't see us having a UI for it.