Home » Eclipse Projects » Plugin Development Environment (PDE) » Ensuring plugin activation at startup
| Ensuring plugin activation at startup [message #4489] |
Wed, 28 May 2008 15:45  |
Eclipse User |
|
|
|
Originally posted by: respond_to_newsgroup.nowhere.com
What is the recommended way to ensure that a plugin is activated when
eclipse starts up? I've looked at the org.eclipse.ui.startup extension
point, but the doc says it's deprecated.
|
|
|
| Re: Ensuring plugin activation at startup [message #4560 is a reply to message #4489] |
Wed, 28 May 2008 17:21  |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Sarah Ettritch wrote:
> What is the recommended way to ensure that a plugin is activated when
> eclipse starts up? I've looked at the org.eclipse.ui.startup extension
> point, but the doc says it's deprecated.
The doc is ambiguous, IIRC. I think it is trying to say that using the
plugin Activator class as the startup extension class is deprecated, not
the entire extension point itself.
Having said that, automatically activating a plugin at startup is
STRONGLY discouraged; Eclipse uses a lazy (on-demand) activation
strategy on purpose - imagine what it would be like if many plugins
decided they needed to be activated on startup... it would take 5
minutes for your workbench to come up.
In other words, if you think you "need" to activate your plugin on
startup, think again. If you still think you "need" to, think again.
Repeat until you realize you don't really need to do it. :-)
Eric
|
|
|
| Re: Ensuring plugin activation at startup [message #4628 is a reply to message #4560] |
Wed, 28 May 2008 19:16 |
| Eclipse User |
|
|
|
Originally posted by: respond_to_newsgroup.nowhere.com
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:g1k48p$2un$1@build.eclipse.org...
> In other words, if you think you "need" to activate your plugin on
> startup, think again. If you still think you "need" to, think again.
> Repeat until you realize you don't really need to do it. :-)
I understand the eclipse lazy-activation strategy, but unfortunately I don't
think I can avoid activating it at startup.
Here's the situation: Plugin B (the one I think I have to activate at
startup) needs to register itself as a listener for events that are
generated when a user interacts with features in Plugin A. The only time A
will ever call into B is when it's notifying registered listeners. A can't
depend on B for packaging reasons--B may not be installed. However, B does
depend on A. If there's a way to tell eclipse to activate B when A is
activated, I can avoid activating plugin B at startup. If not, I think I'll
have to activate B at startup, otherwise it won't be active when events
occur. I'm not aware of any way to link two plugins together like that, but
I may just not have stumbled across it.
The docs *are* ambiguous--I wondered if the deprecated part only applied to
having the Activator implement IStartup. So if I add a class to the plugin
that implements IStartup instead of having the Activator do it, that's okay,
right? Thanks for the clarification.
|
|
|
| Re: Ensuring plugin activation at startup [message #4835 is a reply to message #4628] |
Thu, 29 May 2008 13:59 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Sarah Ettritch wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:g1k48p$2un$1@build.eclipse.org...
>
>> In other words, if you think you "need" to activate your plugin on
>> startup, think again. If you still think you "need" to, think again.
>> Repeat until you realize you don't really need to do it. :-)
>
> I understand the eclipse lazy-activation strategy, but unfortunately I don't
> think I can avoid activating it at startup.
>
> Here's the situation: Plugin B (the one I think I have to activate at
> startup) needs to register itself as a listener for events that are
> generated when a user interacts with features in Plugin A. The only time A
> will ever call into B is when it's notifying registered listeners. A can't
> depend on B for packaging reasons--B may not be installed. However, B does
> depend on A.
I would define an extension point in A to represent listeners of those
events, and then B can implement that extension point with its own
class. That maintains the dependency directionality (B depends on A but
A does not know about B until runtime).
When A is activating, it would get all the extensions (via
Platform.getExtensionRegistry()) that implement its extension point,
instantiate the classes (which will activate the defining plugin, B in
your case), and register them as listeners.
Does that explanation make sense?
Hope this helps,
Eric
|
|
|
| Re: Ensuring plugin activation at startup [message #4899 is a reply to message #4835] |
Thu, 29 May 2008 15:55 |
| Eclipse User |
|
|
|
Originally posted by: respond_to_newsgroup.nowhere.com
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:g1mcpf$3rs$1@build.eclipse.org...
> I would define an extension point in A to represent listeners of those
> events, and then B can implement that extension point with its own class.
> That maintains the dependency directionality (B depends on A but A does
> not know about B until runtime).
> When A is activating, it would get all the extensions (via
> Platform.getExtensionRegistry()) that implement its extension point,
> instantiate the classes (which will activate the defining plugin, B in
> your case), and register them as listeners.
>
> Does that explanation make sense?
Yes, it makes sense. Thanks, Eric. :-)
|
|
| |
| Re: Ensuring plugin activation at startup [message #567502 is a reply to message #4560] |
Wed, 28 May 2008 19:16 |
| Eclipse User |
|
|
|
Originally posted by: respond_to_newsgroup.nowhere.com
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:g1k48p$2un$1@build.eclipse.org...
> In other words, if you think you "need" to activate your plugin on
> startup, think again. If you still think you "need" to, think again.
> Repeat until you realize you don't really need to do it. :-)
I understand the eclipse lazy-activation strategy, but unfortunately I don't
think I can avoid activating it at startup.
Here's the situation: Plugin B (the one I think I have to activate at
startup) needs to register itself as a listener for events that are
generated when a user interacts with features in Plugin A. The only time A
will ever call into B is when it's notifying registered listeners. A can't
depend on B for packaging reasons--B may not be installed. However, B does
depend on A. If there's a way to tell eclipse to activate B when A is
activated, I can avoid activating plugin B at startup. If not, I think I'll
have to activate B at startup, otherwise it won't be active when events
occur. I'm not aware of any way to link two plugins together like that, but
I may just not have stumbled across it.
The docs *are* ambiguous--I wondered if the deprecated part only applied to
having the Activator implement IStartup. So if I add a class to the plugin
that implements IStartup instead of having the Activator do it, that's okay,
right? Thanks for the clarification.
|
|
|
| Re: Ensuring plugin activation at startup [message #567614 is a reply to message #4628] |
Thu, 29 May 2008 13:59 |
 Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Sarah Ettritch wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:g1k48p$2un$1@build.eclipse.org...
>
>> In other words, if you think you "need" to activate your plugin on
>> startup, think again. If you still think you "need" to, think again.
>> Repeat until you realize you don't really need to do it. :-)
>
> I understand the eclipse lazy-activation strategy, but unfortunately I don't
> think I can avoid activating it at startup.
>
> Here's the situation: Plugin B (the one I think I have to activate at
> startup) needs to register itself as a listener for events that are
> generated when a user interacts with features in Plugin A. The only time A
> will ever call into B is when it's notifying registered listeners. A can't
> depend on B for packaging reasons--B may not be installed. However, B does
> depend on A.
I would define an extension point in A to represent listeners of those
events, and then B can implement that extension point with its own
class. That maintains the dependency directionality (B depends on A but
A does not know about B until runtime).
When A is activating, it would get all the extensions (via
Platform.getExtensionRegistry()) that implement its extension point,
instantiate the classes (which will activate the defining plugin, B in
your case), and register them as listeners.
Does that explanation make sense?
Hope this helps,
Eric
|
|
|
| Re: Ensuring plugin activation at startup [message #567680 is a reply to message #4835] |
Thu, 29 May 2008 15:55 |
| Eclipse User |
|
|
|
Originally posted by: respond_to_newsgroup.nowhere.com
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:g1mcpf$3rs$1@build.eclipse.org...
> I would define an extension point in A to represent listeners of those
> events, and then B can implement that extension point with its own class.
> That maintains the dependency directionality (B depends on A but A does
> not know about B until runtime).
> When A is activating, it would get all the extensions (via
> Platform.getExtensionRegistry()) that implement its extension point,
> instantiate the classes (which will activate the defining plugin, B in
> your case), and register them as listeners.
>
> Does that explanation make sense?
Yes, it makes sense. Thanks, Eric. :-)
|
|
|
Goto Forum:
Current Time: Wed Apr 24 20:34:01 GMT 2024
Powered by FUDForum. Page generated in 0.04023 seconds |
] 
Search
Help
Register
Login
Home
