Community
Participate
Working Groups
Firstly I wanted to understand why the startup extension point in org.eclipse.ui is a UI based extension point. Even a non ui plugin can have a need to startup. We need this extension point to be moved to the base platform so we can startup a plugin in headless environment also. If there is valid reason why this has to be a UI base ext. point only please let me know. We currently came accross a situation where the plugin needs to be started up in a headless enviroment also.
are you building an RCP application?
This is not for an RCP application. There are some products which run "headless" against a workspace, where no workbench opens. These products usually are started from a command line. These products will also have the need for hooks to force startups, and therefore it makes sense for this extension point to be defined in a core platform plugin rather than a UI plugin.
Moving to Runtime for comment on why there is no starup ext. pt. in Core.
General statement, automatically started plugins are a bad thing. Everyone thinks that their plugin is important and should be started all the time. Typically they are not in the right position to determine this. Having said that, there are cases where it makes sense and is required. The main challenge is knowning when to start the plugins. Witht he ext pt in UI, the UI can fork and start the plugins when it is up and everything is ready. I believe this to be the historical reason behind the current state. As of 3.0 there is (I shudder to reveal this) another mechanism for starting pluigns. As part of the OSGi framework you can specify various plugins to install and optionally automatically start. Using start levels you can contrive to have these plugins started after all others at previous levels have been started. This does not getyou out of the woods however. There can still be sequencing problems. So summary: It is possible for some autostart mechanism to be exposed by the runtime but it would not be as nice/easy to use as the one in the UI unless we have some notion of appliation lifecycle (proposed elsewhere) so we would know when to start these autostart plugins.
*** This bug has been marked as a duplicate of 80807 ***
I don't think this is a dup as noted. Bug 80807 is about logins etc. This is something that should be done early but separate form the issue here where they want the plugins started but done' really seem to care when. Moving the challenge for runtime doing the work is understanding when we would do it. Currently there is no lifecycle that tells the runtime when the app is up and running. In many cases the early startup extension will expect that the workbench (for example) is up and read to go. At least that is the current contract. The best the runtime could do is fork a thread after starting the application. The thread could wait some amount of time but we'll never get that number right. So, I'm going to reopen, not because I think we can do something but because this bug is separate from bug 80807 and should be assessed on its own merits.
oups.. got confused by the title...
No plans to fix, note potential dependency issue in the comment 6. For [headless] RCP applications it is actually less of a problem as initial osgi bundles list in config.ini could be modified for a given application.
I just wrote a little plugin that listens to resource changes, and when they change it updates working sets. But theres no way to start it because its only a listener, and no other plugin is going to call it. I could use the org.eclipse.ui.startup extension point, but its deprecated. Is there really no replacement?
The org.eclipse.ui.startup extension point is not deprecated.
Then I may have misunderstood this from the extension point description: <snip> If the extension does not provide a class as an attribute on the startup element, the plug-in's activator (plug-in class) must implement org.eclipse.ui.IStartup. Note that this form is deprecated and should no longer be used. Its functioning relies on the availability of the org.eclipse.core.runtime.compatibility plug-in and the org.eclipse.core.runtime.compatibility.registry fragment. <snip> I took it to mean that the whole extension point was deprecated, but I think you're saying its only the activator extending IStartup part that is deprecated? And thats because it relies on the compatibility layer. I take it that there is no way of setting the start level in the bundle manifest?
>If the extension does not provide a class as an attribute on the startup >element, the plug-in's activator (plug-in class) must implement >org.eclipse.ui.IStartup. Note that this form is deprecated and should no longer >be used. The "form" that is deprecated is where the extension does not provide a class attribute. If you specify a class attribute on the extension you are fine and don't need the compatibility support. > I take it that there is no way of setting the start level in the bundle > manifest? No. One option for your particular case is to use a save participant to process deltas that occurred while your plugin wasn't started. http://www.eclipse.org/articles/Article-Resource-deltas/resource-deltas.html#2 Although we don't recommend eager activation because it's not scaleable when many bundles do it, you also have the option of creating an "immediate" Declarative Services component, which will be activated immediately once its dependencies are satisfied. If you create a trivial DS component with no dependencies it will be activated immediately.
