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

Bug 206234

Summary:	Provide "Restart Workspace" Option for Export Plugin / Feature
Product:	[Eclipse Project] PDE	Reporter:	Miles Parker <milesparker>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	agarcher, baumanbr, jeffmcaffer, milesparker, remy.suen
Version:	3.4
Target Milestone:	---
Hardware:	All
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Miles Parker

2007-10-13 14:00:55 EDT

Currently, after exporting a plugin or feature, you must then quit eclipse and restart or select File:Switch Workspace:Other.. and OK to restart the same workspace. I suggest an option under export plugin options tab to automatically restart workspace on export.

Justification:

Current design is awkward for a very common usage, which is developing and testing / using a plugin within the same Eclipse install. While I understand that this approach is not really the blessed way of developing Plugins, I submit that many people develop plugins this way -- as the Eclipse Runtime launch approach is very often not consistent with actual deployment behavior and the runtime plugin configuration can be overly complex, resource and maintenance intensive, and in my experience inconsistent. There don't seem to be significant gains in launch speeds either -- to the contrary in fact depending on combined IDE and Runtime footprint one can easily approach memory limits on typical machines.

As Plugin development is a key part of Eclipse technology and reducing the edit, build, launch, test cycle time is critical to rapid development I think this relatvily small feature would be of real benefit to a significant number of developers.

Comment 1 Adam Archer

2007-10-13 14:18:24 EDT

I have found myself using the "Switch Workspace" trick to restart the same workspace from time to time myself (though no reasons for wanting to restart spring to mind at the moment).

It might be worthwhile to add a "Restart Workbench" option to the File menu.

Comment 2 Miles Parker

2007-10-13 14:29:45 EDT

Agreed..I was going to suggest this as an alternative / addition (with key binding supor, natch). The switch trick is actually mentioned somewhere in the PDE or SDK docs, but it isn't very intuitive, esp. as one's current workspace isn't listed as item.

I am a bit unclear on "no reasons spring to mind", perhaps I really am the only person who uses the restart workbench approach to test changes in plugin UI -- I have found that this is the least exasperating way to deal with plugin development in many cases; say where one is using (other people's :D) plugin dependencies that are inconsistent / improperly configured, causing the eclipse runtime to fail to update them, or in the case where the combined memory footprint of current IDE and similar launched runtime workspace are very large. But as I say, I would be really happy with the "restart" item too!

Comment 3 Jeff McAffer

2007-10-14 11:27:41 EDT

personaly I think it would misleading to have a restart associated with the export in any way.  People will be confused and think somehow that they have to or shoudl restart their IDE.  Honestly I think this is a very niche case.  People should use the target platforms and launch configs IMHO.

Comment 4 Miles Parker

2007-10-14 13:23:20 EDT

Fair enough -- I'll accept that this is an edge case unless there are other users who also report the frequent need to restart their workspace after an export for plugin testing purposes. (If so then perhaps the restart option would only be provided in the case where the user is exporting to the current Eclipse install location.) I've added a bug report bug 206268 for the more general "Restart Workspace" feature request from Adam's comment 1. Not sure if this one is an INVALID or WONTFIX so I'll leave that to others.

(I guess my real issue should be "Runtime Confirguration does not function consistently with export of plugins directly to install location" but that is hardly specific enough for a bug report -- the amount of testing that would be required to track down the exact cause(s) is the reason I have resorted to this other solution. The basic issue seems to be that Eclipse Runtime cannot find some included resources while I have no such issues with my plugins when installed in an actual Eclipse install.)

Comment 5 Brian Bauman

2007-10-15 11:17:40 EDT

Hi Miles, I agree with Jeff that this might be confusing or misleading.  The stereotypical development process would be to develop and test your plug-in using the runtime workbench.  When you have finalized your development and are ready for deployment, the user would then go ahead and export the plug-in.  We understand this process does not work for everyone :) (though I believe it does work for most).

I would be much more inclined to try to fix the problem you described in comment #4 so we could stream line your development process.  If you could post back to this bug report with the discrepancy between the runtime workbench and the running from the command line, we might be able to help figure out (or possibly already know) the problem.

As our slogan goes "In PDE we do tooling, but our business is people!"

Comment 6 Miles Parker

2007-10-15 16:31:51 EDT

:D Thanks for the encouragement. Honestly it is quite possible that I have screwed something up on configuration and the runtime case is simply exposing a failure that my IDE setup is somehow masking. Sometimes its hard to know the sweet spot between 'suffer through' and 'investigate' given other priorities, especially as in this case when the range of possible issues crosses many different projects -- in this case so far EMF, oAW, PDE, OSGI and possibly JDT.

Briefly ;), I have a dependency from an EMF model to another EMF resource that I am loading from an EMF URI mapping, and OSGI is reporting that it can't find the bundle entry. I get a FileNotFoundE in ..osgi.framework.internal.protocol.bundleentry.Handler.findBundleEntry [42]. (Unfortunatly I would have to post a gif of the actual error as I can't copy the error text from the EMF editor..)

As I start to isolate things I am finding that my assumptions about how the runtime Application works are simply wrong and now as I try to set things up in the 'right' way I am finding it difficult to figure out how I can even set up my runtime environment matches my installation.

I had assumed that "All workspace and enabled plugins" would mean that my Eclipse install plus my Workspace plugins would be used. But I'm realizing that _features_ are not being included. If or how this might affect resource loading I'm not sure but it is the one major difference I see between the two configurations. I am finding that the warnings I get on startup are significantly different -- for example equinox reports version issues from trying to use an earlier version.

My guess it that the fundamental issue is that I have had to do manual installations of features and plugins because of incompatibilties between various milestone and interim features and plugins or because certain features do not have update sites for current builds. The runtime application is somehow trying to be cleaner about things and is reconfiguring / 'fixing' things such that Eclipse Install + My new features/plugins != Runtime + My new features/plugins. I do use -clean religiously and create new configuration areas and workspaces for testing. Don't know if that makes any sense and I continue to investigate as time allows, but pls let me know if there is anything in praticular that might help isolate issues further..

Comment 7 Brian Bauman

2007-10-15 18:56:16 EDT

I can understand why you would not want to spend too much time investigating that issue.

My first suggestion would be to post something to the EMF mailing list really quick to see if anyone else has seen anything similar.  If they have, they might have a solution for you.

Second, you can actually set up your runtime workbench to run with features.  Check out this link to PDE Tips and Tricks, it should be the 3rd one on the list http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.pde.doc.user/tips/pde_tips.htm

Unfortunately, I have not heard of anything like what you are describing, but if there is some other way we could help, please let us know.

Comment 8 Miles Parker

2007-10-15 19:27:45 EDT

Thanks Brian..

The resource issue is a long going one that has a lot to do with (too obscure to go into here but can't quite lay it at EMF doorstep) runtime class-loading issues among other things...a few months ago I got things to the point where deployed features/plugins worked fine but the runtime launch didn't and so finally gave up.

Anyway, thanks for the link about simulated startup with workspace features -- I had tried this at some point but was discouraged by the fact that it would require me to place all of the project related plugins in one giant workspace. (I have three sets of feature targets which are largely orthognal but overlap over 30+ projects when collaborators are included. My style is to keep these in seperate workspaces and create spanning workspaces with relevant subset of plugins imported.) If I could use plugins that I'd imported without moving that would be great, but my understanding is that I have to actually copy them in. 

But if I can't get this resolved some other way I think that is going to be the way I'll have to go.

Comment 9 Miles Parker

2007-10-16 12:43:42 EDT

As an update, I think I have isolated a pretty strong case. Please do let me know if this is more appropriatly addressed in a new report and/or newsgroup.

I have done a clean install using update manager for all except my own plugins and have narrowed things down to just four of my PDE projects. I copied the four relevant plugins only into a new workspace and created new runtime application, new configuration areas and workspaces. So I have determined that the issue is not features -- as I export only the relevant plugins without enclosing features into my new eclipse install, regardless of wether I deploy as jars or not, the behavior works as expected, but still fails under the launched runtime. Also, I have tried launching with plugins and also set up an environment for launching with simulated features. I think I now have a potential candidate for the issue.

First, are there any documents that describe the differences between an eclipse launch and a runtime launch?

This is the exception I'm getting that seems relevant...this causes simulated startup to fail but allows plugin startup to continue. However, it also occurs on subsequent regular workspace launches and yet that case still works fine. Is it possible that the runtime launch somehow relies on this socket to deliver plugin resources?

org.osgi.framework.BundleException: Exception in org.eclipse.equinox.jmx.internal.server.Activator.start() of bundle org.eclipse.equinox.jmx.server.
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:289)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1269)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:788)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:252)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:49)
at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:248)
at org.eclipse.ui.internal.EarlyStartupRunnable.getExecutableExtension(EarlyStartupRunnable.java:117)
at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:66)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ui.internal.Workbench$54.run(Workbench.java:2190)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.rmi.server.ExportException: Port already in use: 8118; nested exception is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249)
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116)
at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:78)
at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:186)
at org.eclipse.equinox.jmx.internal.rmi.RMIServer.initialize(RMIServer.java:51)
at org.eclipse.equinox.jmx.internal.rmi.RMIServer.newJMXConnectorServer(RMIServer.java:38)
at org.eclipse.equinox.jmx.internal.server.JMXServerFactory.createJMXServer(JMXServerFactory.java:49)
at org.eclipse.equinox.jmx.internal.server.Activator.createServer(Activator.java:94)
at org.eclipse.equinox.jmx.internal.server.Activator.start(Activator.java:61)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
... 28 more
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at java.net.ServerSocket.<init>(ServerSocket.java:97)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:622)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:237)
... 43 more
Root exception:
java.rmi.server.ExportException: Port already in use: 8118; nested exception is:
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249)
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116)
at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:78)
at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:186)
at org.eclipse.equinox.jmx.internal.rmi.RMIServer.initialize(RMIServer.java:51)
at org.eclipse.equinox.jmx.internal.rmi.RMIServer.newJMXConnectorServer(RMIServer.java:38)
at org.eclipse.equinox.jmx.internal.server.JMXServerFactory.createJMXServer(JMXServerFactory.java:49)
at org.eclipse.equinox.jmx.internal.server.Activator.createServer(Activator.java:94)
at org.eclipse.equinox.jmx.internal.server.Activator.start(Activator.java:61)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:289)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1269)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:788)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:252)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:49)
at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:248)
at org.eclipse.ui.internal.EarlyStartupRunnable.getExecutableExtension(EarlyStartupRunnable.java:117)
at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:66)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ui.internal.Workbench$54.run(Workbench.java:2190)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at java.net.ServerSocket.<init>(ServerSocket.java:97)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:622)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:237)
... 43 more