Community
Participate
Working Groups
see bug 27359 the core boot part of update currently can recognize when a new feature is laid down in an install. When it discovers this, it passes -newUpdates on the command line to the rest of the platform startup. The workbench looks for this and when it sees the flag, runs the update UI to ask the user if they want to install the newly laid down features. After this the platform is restarted. The workbench's job however is not over. It still has to discover new prespectives, open the welcome page, etc. To do this they ask update core some questions. This causes a lot of code to be loaded and work to be done. This is ok if it is only done the first time after a feature is *installed*. Unfortuatnely, there is no lifecycle that tells the workbench so they have to do the code on every startup. 99% of the time there are no new features so the work was wasted and the code needlessly loaded. So, the question. Is it possible for the core part of update to generate the desired lifecycle (say as a -installedUpdates) which the workbench (or others) could use to tell if they need to do the work described. Basically update would need to remember a token (hash or something) representing the last run and compare it to the has for the current run. If they are different then updates were installed. (that about over extends my limited knowledge of how this code works :-)
Bug 27359 is marked for M4 but it depends on this bug. Should we mark this one for M4 as well?
Let me restate what I undertsood, tell me if this is valid UI wants to be triggered after new feature have been enabled so UI can find if the new feature contribute to perspective and other ui extension point. I am wondering, is it different than the algorithm we use to refresh the plugin repository structure in core? So UI can get our hash from platform.cfg (the feature hash) and compare it with the previous one they saved ? Thoughts ?
BootLoader.getCurrentPlatformConfiguration().getFeaturesChangeStamp() returns the hash of configured features. This does not involve update.core.
Sounds like a good suggestion. The workbench could simply remember the last features change stamp, and only check Update Core for new features if it has changed. This would eliminate most of the checks. Unfortunately it would not eliminate the check the first time Eclipse is started though, unless there's some other special flag for this case.
can you elaborate re the first time ? If you do not have any state, it means it is the first time no ?
Good point <g>.
Added the fix based on getFeaturesChangeStamp(). The update plugin will be activated the first time the workbench is started because we need to build a collection with all features and open the welcome pages.
I thought we just presented the main product's welcome page on first start?
Looks like we don't need the extra lifecycle after all.
