[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Thoughts about ECF connection ui
|
Hi everyone,
Remy Suen wrote:
Hi everyone,
<stuff deleted>
Actually, I was trying to talk to Erkki here. I shouldn't have quoted
your subsequent follow-up paragraph, sorry. :/ He had mentioned
"startup" so I wanted to check if he meant workbench, ECF core, or
OSGi (or something else entirely?) since the methods necessary to
perform an "auto-whatever" on its startup are different for each case.
Anyway, the point of my email was to explain to Erkki that the ECF
plug-in, assuming IECFStartup was used, is never going to start unless
you specifically set it so prior to booting up the framework
True...or it's set to startup as part of application launch (e.g. RCP
app, or Equinox server app).
, or by
manually activating it (say, through the OSGi console), or some other
means (through the UI examples I described previously, which in this
case the org.eclipse.ui.startup extension would probably be better).
There may be other ways to boot up a bundle, but unfortunately, I
don't know OSGi as well as I'd like.
I agree with Chris here in that the UI extension is probably
sufficient for our needs. When the new UI work begins, I think the
auto-connect stuff should be delegated to the ui startup extenson
point. In a headless framework-only context, the entry point (likely
the main(String[]) or start(BundleContext) method, or maybe even the
org.eclipse.core.products or org.eclipse.core.application extension
points?) of the application being run would probably perform all the
necessary initialization work anyway, so I think it is questionable as
to whether IECFStartup will be useful to developers at all.
I also think it will be of limited usefulness. You are right of course
that it won't be generally useful for launching an ECF-based application
(RCP or server app, set) as it's dependent upon the OSGi/Equinox 'lazy
loading' model. OTOH, if one was to have the ECF core plugin started
via the org.eclipse.configurator (name?) upon Eclipse/RCP/server start,
then the ECF startup extension could be (mildly) useful.
Of course, I suppose I'm technically already wrong here since it seems
Erkki might have some use cases in a headless context for doing some
autoconnection work (assuming we're talking about ECF core startup).
So I guess my question is why run Runnable-ish-like stuff elsewhere
through extension points in a non-UI context when it's probably just
as easy to take care of it yourself within your own thread(s)? ECF
core, after all, doesn't really have anything interesting in my
opinion that warrants an "I must do this before the rest of ECF
activates"...besides maybe ContainerFactory?
Also the IDFactory in identity extension point. And it might be useful
in some runtime contexts (e.g. without extension registry service) to
initialize these factories in code rather than declaratively...but I'm
speculating, of course. :)
If we do keep the startup extension, it'd probably be a good idea to
clearly indicate to the user when it will actually run and that there
is the org.eclipse.ui.startup extension point for UI business if the
user is actually trying to go that route.
True. I'll try to add some documentation to the extension point
definition to this effect. We should also point to the Equniox docs on
the startup/configurator mechanisms...I'll see if I can track some down.
Thanks,
Scott
