Community
Participate
Working Groups
Pat McCarthy/Raleigh/IBM@IBMUS Sent by: platform-update-dev-admin@eclipse.org Based on testing it looks like the change log kept by the Update Manager remembers 5 changes. We may need to consider increasing this number or packaging changes differently. I started/stopped a base workbench, added a feature link file and started/stopped, added a 2nd feature link file and again started/stopped. My change log file is full - any other mods and it will runeth over. Content below based on the system summary (I've added the ----- for visibility): Update Manager Log: Configuration=Jun 4, 2002 11:53:14 AM Current configuration=false Date=Tue Jun 04 11:53:15 EDT 2002 Target=file:E:/Eclipse-int-06-02/eclipse/ Action=Site installed Status=Success Date=Tue Jun 04 11:53:15 EDT 2002 Target=file:E:/Eclipse-int-06-02/eclipse/.config/platform.cfg.metadata/LocalSite .xml Action=Reconcile Status=Success ---------------------------------------------------- Configuration=Jun 4, 2002 11:56:02 AM Current configuration=false Date=Tue Jun 04 11:56:02 EDT 2002 Target=file:e:/Eclipse-int-06-02/GEF/Runtime/eclipse/ Action=Site installed Status=Success Date=Tue Jun 04 11:56:02 EDT 2002 Target=file:E:/Eclipse-int-06-02/eclipse/ Action=Site installed Status=Success Date=Tue Jun 04 11:56:03 EDT 2002 Target=file:E:/Eclipse-int-06-02/eclipse/workspace/.metadata/.config/platform.cf g.metadata/LocalSite.xml Action=Reconcile Status=Success ---------------------------------------------------- Configuration=Jun 4, 2002 11:56:35 AM Current configuration=false Date=Tue Jun 04 11:56:35 EDT 2002 Target=com.ibm.etools.gef_2.0.0 Action=Enabled Status=Success ---------------------------------------------------- Configuration=Jun 4, 2002 11:59:11 AM Current configuration=false Date=Tue Jun 04 11:59:11 EDT 2002 Target=file:e:/Eclipse-int-06-02/GEF/Runtime/eclipse/ Action=Site installed Status=Success Date=Tue Jun 04 11:59:11 EDT 2002 Target=file:e:/Eclipse-int-06-02/GEF/Examples/eclipse/ Action=Site installed Status=Success Date=Tue Jun 04 11:59:11 EDT 2002 Target=file:E:/Eclipse-int-06-02/eclipse/ Action=Site installed Status=Success Date=Tue Jun 04 11:59:11 EDT 2002 Target=file:E:/Eclipse-int-06-02/eclipse/workspace/.metadata/.config/platform.cf g.metadata/LocalSite.xml Action=Reconcile Status=Success ---------------------------------------------------- Configuration=Jun 4, 2002 11:59:27 AM Current configuration=true Date=Tue Jun 04 11:59:27 EDT 2002 Target=com.ibm.etools.gef.examples.logicdesigner_2.0.0 Action=Enabled Status=Success As soon as I maintain one of the linked (extension)features I loose visibility to the first two actions. This seems to be due to the two-pass processing where each pass (install/reconcile and then enable) is a logged event. Can we consider either doubling the number of log entries or managing the log such that an install/reconcile and then enable is one logged event? Pat Mc.
F3 candidate
As an alternative, consider maintaining a full change log as a file that is appended on each install action (as part of writing new histories). This would be exposed via the About instead of the current history dump. Also, may consider dumping the current configuration with any status showing (warnings, errors)
At least changing the default to a value beyond 5 (say 50) is an absolute (P1) rqmt per the product teams. If we do this - we should also reverse the order of display in the Update manager list... I'd rather have the active at the top and the order by FILO. Also - I just noticed, and only by picking up my tpad (1400x1050) and brining it close to my face, the running man icon overlay on the config. Maybe it should be offset a bit more, be a color, or be in the top right corner (or all of the above). View may be that this is more important than P3 (to get product team buy-in).
The separate log idea is best. Then we can have a permanent history which is what we need for support. At that point how large the undo stack is irrelevant to us WS tools. We need the history.
A separate log is a good suggestion for post 2.0 work. The near term fix is to increase the size of the history from 5. The size is controlled by an Install/Update preference, and is already accessible through the workbench UI. If the preferences is advertized as API, a product's plugin_customization.ini file could change the default value.
A separate problem (19390) is preventing plugin_customization.ini from working.
Don't like the idea of having to ask (as we would have to do in our RFWS validation) for all installs to adjust the default. If one plug-in could do this for all - fine. But as I understand it today, only the primary feature/plugin can adjust preferences via the customization.ini file approach. Looking like we must do one or more of the following (product team pressures): -Have the default raised to a reasonable number (50 or more) -Reverse the order of display in update manager -Limit the undo list in update manager to a shorter list than what is there in the history (would provide a logical log/undo separation) That said, customers on service calls will be asked to disable/enable recent activity - and we don't want to loose this if the list is short. Begs for a guide for the customer/service rep on how to approach making config changes: 1. save current config and adjust name to have a meaningful name (wish I could do this with F2). 2. Make config changes or undo recent updates. 3. Test behavior - return to 2 if required. 4. Commit config for runtime use 5. Save config and adjust name to have a meaningful name
Initial changes released into HEAD together with fix for bug 19390. The order of histories and preservede states is reversed (most recent to least recent). The default is increased to 10. However, update.core is still not handling this correctly (trimming at 5) so keeping defect open. NOTE: F2 does have the ability to save the current configuration. The UI is not the most intuitive, so we should change it post 2.0 .... but the user can open Histories, and the most recent history == current configuration (has running man on the icon ... again, should fix visibility of the overlay post 2.1). Right click, Save, then go to the newly preserved configuration (in the Preserved folder) and change its name (right click, Properties). Like I said, the UI flow for this operation leaves lot to be desired, but the function is there. There is no limit on the number of preserved histories.
Increased default number of histories to 50 as per conversation with Jim. Released interim workaround for 2.0 for handling of the preference setting between update core and update UI. Post 2.0, need to split out the use of histories for undo, and a separate service log. Opening a separate defect to track this
