Community
Participate
Working Groups
I don't know what happened. I installed 3.2 M6 yesterday evening and I'm pretty sure it prompted for a workspace. However, this morning it starts without prompting for a workspace although the preference is set. It always opens the workspace in <MY_WINDOWS_PROFILE>\workspace. This is the content of my configuration/.settings/org.eclipse.ui.ide.prefs file. #Sun Apr 02 10:44:21 EDT 2006 RECENT_WORKSPACES_PROTOCOL=2 MAX_RECENT_WORKSPACES=10 SHOW_WORKSPACE_SELECTION_DIALOG=true eclipse.preferences.version=1 RECENT_WORKSPACES=D\:\\Development\\.......<more workspaces> I start Eclipse using "eclipse.exe -vmargs -XX:+UseParallelGC". If I go to Window->Preferences->General->Startup the prompt for workspace preference is checked.
That's weird. After restoring the content of my backup file from yesterday the prompt appears again.
Ignore comment #1. It is related to one of my workspaces. As soon as I start this workspace and exit Eclipse the next time it starts with the default workspace (without prompting). And now the most curious part. If I delete the folder configuration\org.eclipse.osgi\.manager then the workspace prompt reappears.
(Applies to M6)
*** Bug 133569 has been marked as a duplicate of this bug. ***
I was not able to reproduce this. I would be very interested in a workspace (and configuration directory) with which this can be reproduced. I'm suspecting this has something to do with us (or someone else?) accessing the instance location before we have a chance to prompt. DJ, do you know of any core-level changes that could affect the instance location before the IDEApplication gets to check if it is already set?
Interesting detail (copied from bug 133569): "Starting with -clean will prompt but removing the -clean will revert back to starting on the default workspace location without prompting."
well, i have the same issue. one thing i found though is that if i do not install my own extension sites then things look ok. my 2 cents.
I also use an extension site to load EMF so it may be related to that.
I can confirm that starting with "-clean" also brings the prompt back. Thus, the severity can be reduced because a workaround is available. ;) Boris, I can share my workspace if your are interested. But I think it's workspace independent. I'm also using different extension sites (some extension as links in the links directory and some added manually via UM).
Created attachment 37520 [details] replacement jar (org.eclipse.osgi_3.2.0.v20060328.jar) for debugging that prints stack traces
Created attachment 37522 [details] startup trace
Looks like the WST plug-in is accessing the instance preferences before the data location is set?
Created attachment 37535 [details] Startup stack I don't think it's WTP only. Looks like it's mylar in my case.
I just talked to Jeff and John and we "narrowed it down": The WTP plug-in accesses its preferences before we get to prompt for the workspace location. The stack trace shows that the WTP plug-in was started explicitly (rather than lazily) in a previous session and is therefore started eagerly in this session. The reason for this seems to be one of - UI's IDEWorkbenchWindowAdvisor.openWelcomeEditors() - deprecated 2.1 APIs - Plugin.start() and IPluginDescriptor.getPlugin() - WTP starting a plug-in explicitly
Created attachment 37536 [details] Working startup stack For comparison, here is a startup trace taken with the "-clean" argument.
Correction to comment #14: it wasn't Plugin.start(), but the Plugin(...) constructor
I was able to reproduce this on my machine.
With WTP? Mylar? Base Eclipse?
I'm seeing this bug on 3.2M6 with WTP I200603302119 and Subclipse 0.8.102. After a fresh install of Eclipse+WTP, I was prompted for the default workspace, which I accepted. I installed Subclipse via an update, which required a restart. The next time I tried to start Eclipse from scratch, I was not prompted for a workspace, even though "prompt" was selected in the preferences. If I switch workspaces during a session, after restart I am placed back in the default workspace. In response to Comment #14, I note that in Bug 130571 WTP finally made some modifications so that it wouldn't screw up the Subclipse menus. I have no idea if those fixes are related to this bug.
Created attachment 37549 [details] stack trace for the first start of InternetPlugin I reproduced this with an extension site containing WTP M5. See the attached stack trace for how the plug-in is started the first time.
Steps: - have a plug-in which implements the UI's IEarlyStartup extension - extension does NOT specify a class to run (by default this loads the Plugin class) - start Eclipse - shutdown On second startup, this plug-in is attempted to be restarted, before the application has begun to run.
Created attachment 37551 [details] example plug-in for reproducing the problem Here is what I did to reproduce this (see the attached plug-in project) - Markup in plugin.xml: <extension point="org.eclipse.ui.startup"/> - The plug-in's activator class must implement IStartup. - To reproduce the "no prompt on startup", the plug-in activator class must be a subclass of AbstractUIPlugin, and call getPreferenceStore() from its start() method. - export the plug-in as a deployable jar and put it in the plugins directory of a clean 3.2M6 install - start Eclipse (workspace prompt appears), then exit again - start again (make sure you don't pass -clean), Eclipse comes up without prompting
So the bug is in runtime compatibility, which calls Bundle.start() when IPluginDescriptor.getPlugin() is called. This will happen for any plugin that uses the org.eclipse.ui.startup extension point without specifying a class name (and anyone else using IPluginDescriptor.getPlugin).
I've been working on a patch to this issue. I will attach it soon ...
Created attachment 37566 [details] patch Patch to both org.eclipse.core.runtime and org.eclipse.core.runtime.compatibility. This patch will attempt to load a class from the plugin first instead of explicitly calling the Bundle#start(). This will allow lazy started bundles to be activated without forcing them to be persistently started on a restart. DJ/John please review and release if approved.
Boris, IDEWorkbenchWindowAdvisor#openWelcomeEditors does explicitly call Bundle#start. Are you looking into changing that? Is there a separate bug report on that?
Re: comment #26 > Boris, IDEWorkbenchWindowAdvisor#openWelcomeEditors does explicitly call > Bundle#start. Are you looking into changing that? Is there a separate bug > report on that? I filed bug 134648 to track this. Thanks for reminding me!
My 2c... This is an important bug to fix rather than backing out of the change to persisting the start state of lazy bundles. Without the persistence refinement it would be quite difficult for people to use other bundles that happen to call start in combination with bundles that are marked as lazy start.
I'm wondering if we should even bother falling back to bundle.start() in the case where the class loading failed to activate the bundle? This means someone is using legacy 2.1 APIs to activate a bundle that does not support LazyStart. In this case they won't be aware of the consequence that they will cause the bundle to be auto-activated in all future sessions. Failure seems like a better option here (i.e., don't support lazy activation of plugins that don't have the LazyStart directive).
*** Bug 134672 has been marked as a duplicate of this bug. ***
Having the same problem. Seems to be mylar and wtp in my case. Why is this bug still marked as new?
*** Bug 134715 has been marked as a duplicate of this bug. ***
Just adding myself to the CC list here - also having the issue and using WTP, and am interested in the final solution...
Created attachment 37644 [details] patch taking comment 29 from John into account. I agree we should avoid calling Bundle#start here. This patch does not call it and will throw an exception if the bundle is lazy started. We do not want to start throwing exceptions for non-lazy started bundles. Instead we need to fail silently here. There are cases of non-lazy started bundles which we do not want to activate explicitly (org.eclipse.pde is one example). It would be problematic to start logging errors/warnings for these bundles.
Looks good. I have also verified that this patch works with Boris' sample bundle.
+1 - the latest patch looks good.
*** Bug 134992 has been marked as a duplicate of this bug. ***
+1
The latest patch has been released.
Verified in N20060407
*** Bug 135421 has been marked as a duplicate of this bug. ***
*** Bug 135520 has been marked as a duplicate of this bug. ***
Just for the record (since this is marked as a greatbug): Michael Valenta was the first to file this bug, see Bug 133569.
*** Bug 135805 has been marked as a duplicate of this bug. ***
*** Bug 136058 has been marked as a duplicate of this bug. ***
*** Bug 136699 has been marked as a duplicate of this bug. ***
I am still seeing this problem in RC1. Is it because the startup state has been persisted from when the problem was introduced? Do I need to disable and reenabled the plugin causing the issue?
(In reply to comment #47) > I am still seeing this problem in RC1. Is it because the startup state has been > persisted from when the problem was introduced? Do I need to disable and > reenabled the plugin causing the issue? I think you need to start with the "-clean" argument at least once. To get a fresh state.
Yes, that worked for me. I hesitated because I thought it would remove my extension locations.
*** Bug 140760 has been marked as a duplicate of this bug. ***
Hi Thomas, I wish to know how to apply this patch in my eclipse . I have downloaded the .patch file . I read somewhere that i could make a featured Patch project and then apply . Am i doing this in the right way ? please help or could you guide me to the correct documentation? Thanks in advance, Bhuvana
(In reply to bhuvana jag from comment #51) > Hi Thomas, > I wish to know how to apply this patch in my eclipse . > I have downloaded the .patch file . > I read somewhere that i could make a featured Patch project and then apply . > > Am i doing this in the right way ? please help or could you guide me to the > correct documentation? > > Thanks in advance, > Bhuvana What version of Eclipse are you using. This was fixed in 3.2 SR1 (8 years ago). Are you really patching an earlier version? Do you see this issue in a later release?
Hi Thomas , I am using Version: 3.5.2.R35x_v20100119 Build id: M20100211-1343 I tried checking for updates from eclipse but still the issue persists. Even -clean doesn't work for me. Could you please help. Regards, Bhuvana
I have an RCP based on Luna, and this problem still exists. I tried starting with -clean, and checking the preference to prompt for workspace location on startup. Nothing I found works.
I have an RCP app based on Luna, and this problem still exists. I tried starting with -clean, and checking the preference to prompt for workspace location on startup. Nothing I found works.
