Bug 134648 - [Intro] IDEWorkbenchWindowAdvisor should not call Bundle#start
Summary: [Intro] IDEWorkbenchWindowAdvisor should not call Bundle#start
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.2 RC1   Edit
Assignee: Boris Bokowski CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-03 23:00 EDT by Boris Bokowski CLA
Modified: 2006-06-02 15:25 EDT (History)
5 users (show)

See Also:


Attachments
patch (1.16 KB, patch)
2006-04-12 15:36 EDT, Boris Bokowski CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Boris Bokowski CLA 2006-04-03 23:00:48 EDT
IDEWorkbenchWindowAdvisor#openWelcomeEditors calls Bundle#start explicitly. This causes the bundle to be started eagerly the next time Eclipse comes up. We should change it so that this does not happen.

Tom, what is the recommended way of dealing with this? The reason for starting the bundle at that time (before showing the welcome editor) is to give it a chance to perform first-time initialization tasks. Should we use deprecated methods from core.compatibility?

Just for context: Welcome editors are deprecated and have been replaced by the "intro" support for some time now. (I believe intro was introduced in 3.0).
Comment 1 Boris Bokowski CLA 2006-04-03 23:02:12 EDT
CC'ing Kim as the owner of the [Intro] component area.
Comment 2 Boris Bokowski CLA 2006-04-03 23:03:55 EDT
(See bug 134412 for the context in which we found this issue.)
Comment 3 Gunnar Wagenknecht CLA 2006-04-04 07:59:27 EDT
I think there should be a story for dropping compatibility support. IMHO the old welcome pages are a good candidate for Eclipse 4.0 ;)
Comment 4 Thomas Watson CLA 2006-04-04 15:09:45 EDT
Actually, If I understand the code correctly, I would recommend you continue to call bundle.start() in this case, but you should immediately call bundle.stop after the activation (in a finally block on the surrounding try to bundle.start).  I only recommend you do this if the following is true:

1) This is only done when a legacy plug-in defines a deprecated wecome editor.
2) This is only done when a new feature is installed and you ensure that you do not call bundle.start and bundle.stop when you restart from a cached state.

I assume this is the case because of the call to wbAdvisor.getNewlyAddedBundleGroups().  I assume this returns an empty set if you restart from a cached state.
Comment 5 Jeff McAffer CLA 2006-04-04 15:25:32 EDT
seems pretty strange.  What sort of initialization is likely to be done?  seems like it would be good to get out of this situation if at all possible
Comment 6 Boris Bokowski CLA 2006-04-04 15:37:06 EDT
Nick, would you be able to respond to Jeff's comment #5 ?
Comment 7 Nick Edgar CLA 2006-04-04 16:27:55 EDT
IIRC, WSADIE needed to do some post-install configuration.  I believe it only starts the feature plugins for newly-installed features.
I believe the old code just used IPluginDescriptor.getPlugin(), which didn't have the "if you start me up, start me up I'll never stop" behaviour.

We'd have to check with KevinM or Greg to see if it's still an issue.  I'll email them.
Comment 8 Boris Bokowski CLA 2006-04-12 14:44:17 EDT
Nick, did you get a response yet?
Comment 9 Nick Edgar CLA 2006-04-12 15:08:20 EDT
No, I asked Greg but did not get a response.
Since AFAIK nobody uses the legacy welcome editors anymore, I don't think this is a significant issue.  I suggest following Tom's recommendations in comment 4.  His assumptions are correct.

Comment 10 Boris Bokowski CLA 2006-04-12 15:36:02 EDT
Created attachment 38439 [details]
patch
Comment 11 Boris Bokowski CLA 2006-04-12 15:36:41 EDT
Tom, could you have a look at the patch?  Is this what you suggested in comment #4?
Comment 12 Thomas Watson CLA 2006-04-12 15:42:49 EDT
+1 patch looks good.
Comment 13 Boris Bokowski CLA 2006-04-12 15:45:07 EDT
Released >20060412
Comment 14 Boris Bokowski CLA 2006-06-02 15:25:20 EDT
Verified using I20060602-0010.