Home » Eclipse Projects » Equinox » Debugging/Testing Plugins, where is the dynmaic behaviour??
| Debugging/Testing Plugins, where is the dynmaic behaviour?? [message #78199] |
Thu, 30 November 2006 14:27  |
Eclipse User |
|
|
|
Originally posted by: tonimenzel.gmx.de
Hi,
Coming from an osgi background (I digged inside of apache felix to get
familar with osgi and separate plain osgi concerns from eclipse stuff)
i wonder about the most obvious way to launch a (small) plugin written
in the PDE: it is, launching a separte Workbench/App with my (new)
plugin inside.
That's 1998!! I think (hope so!!) it is not a limitation of the platform
layer of eclipse (workbench) above osgi requiring my weak G4 powerbook
(nice but.. well not that superb fast) to load a new workbench on each
development step..
As I mentioned above coming from the osgi experience, I would assume a
plain bundle-update on just the changed bundle and everything is fine
(things come and go..)
Is anybody here with some short advice/tips?
To control things, i would appriciate having the equinox-shell launched
inside my PDE and controlling plugins that that way.
However, there must be the osgi way to update things inside the PDE.
kind regards,
Toni
|
|
| |
| Re: Debugging/Testing Plugins, where is the dynmaic behaviour?? [message #78289 is a reply to message #78215] |
Fri, 01 December 2006 00:09  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
What you are looking for is what the PDE folks call "extreme
self-hosting". That is the ability to "launch" an existing
configuration. PDE, rather than starting a completely new instance of
Equinox would just perform the various provisioning operations to make
some running one look like the requested launch configuration. There
has been some thinking and investigation in this direction but its not
clear what will happen for 3.3.
From you second note I also infer that you are looking to test/run your
code in the same Eclispe that you are using to develop it. Most of the
original Eclipse team were Smalltalk hackers so this was the only way we
worked. However, Java is not Smalltalk and this approach would likely
quickly devolve into a gooey mess of quivering classes and bytecodes.
If all you are looking to do is play with extensions, create a new
Plugin Project and spec that you are making an RCP application. then
pick one of the more complicated templates that you will be presented
(say the mail example). That will give you a small example app with
which you can play and launch in < 1-2 sec.
Of course, you could also just create your own bundles that define
extensions and extension points and lauch using an Equinox launch
configuration...
Jeff
Toni Menzel wrote:
> to make things more specic:
> I try to get familar with the eclipse way of DS: Exensions and
> ExtensionPoints.
> So I write a plugin contributing a extension to a ui extensionpoint
> inside the current worbench (let's say a view for example).
> So I do not want a new framework instance (either worbench or just
> equinox), i just want to plugin in my development-effort into my running
> environment.
>
> hope this makes this newsgroupentry more comprehensible..;-)
> Toni
>
> Toni Menzel schrieb:
>> Hi,
>>
>> Coming from an osgi background (I digged inside of apache felix to get
>> familar with osgi and separate plain osgi concerns from eclipse stuff)
>> i wonder about the most obvious way to launch a (small) plugin written
>> in the PDE: it is, launching a separte Workbench/App with my (new)
>> plugin inside.
>> That's 1998!! I think (hope so!!) it is not a limitation of the
>> platform layer of eclipse (workbench) above osgi requiring my weak G4
>> powerbook (nice but.. well not that superb fast) to load a new
>> workbench on each development step..
>> As I mentioned above coming from the osgi experience, I would assume a
>> plain bundle-update on just the changed bundle and everything is fine
>> (things come and go..)
>>
>> Is anybody here with some short advice/tips?
>> To control things, i would appriciate having the equinox-shell
>> launched inside my PDE and controlling plugins that that way.
>> However, there must be the osgi way to update things inside the PDE.
>>
>> kind regards,
>> Toni
|
|
|
| Re: Debugging/Testing Plugins, where is the dynmaic behaviour?? [message #78304 is a reply to message #78289] |
Fri, 01 December 2006 05:55 |
| Eclipse User |
|
|
|
Originally posted by: tonimenzel.gmx.de
thanks Jeff for the quick and detailed answer!
So thinks are more complex than expected.. and: your second assumption
(smalltalk-hackers) is the one I am looking for in sample.
But.. can you (or someone at the newsgroup) explain me why the following
scenario is not "possible" currently (or at least not well accessable):
- I create a new plugin project, select the view-template to get started
with a very simple but visible thing.
- This bundle contributes functionality (here widgets) to the eclipse-ui
(a new fancy view)
Now: what is the problem in a osgi based mechanism to add the bundle to
the (already running inside of my development-eclipse-instance) equinox
container, let it resolve and launch.
The servicelayer then should trigger a contribution to the list of
available views.
Done.
I really thought osgi was about not having to "devolve into a gooey mess
of quivering classes and bytecodes".. so, does the PDE have so many
layers between itself and core osgi that it does not "see the forrest
because of too much trees" (.. german saying, hope you know what I mean)
Toni
Jeff McAffer schrieb:
> What you are looking for is what the PDE folks call "extreme
> self-hosting". That is the ability to "launch" an existing
> configuration. PDE, rather than starting a completely new instance of
> Equinox would just perform the various provisioning operations to make
> some running one look like the requested launch configuration. There
> has been some thinking and investigation in this direction but its not
> clear what will happen for 3.3.
>
> From you second note I also infer that you are looking to test/run your
> code in the same Eclispe that you are using to develop it. Most of the
> original Eclipse team were Smalltalk hackers so this was the only way we
> worked. However, Java is not Smalltalk and this approach would likely
> quickly devolve into a gooey mess of quivering classes and bytecodes.
>
> If all you are looking to do is play with extensions, create a new
> Plugin Project and spec that you are making an RCP application. then
> pick one of the more complicated templates that you will be presented
> (say the mail example). That will give you a small example app with
> which you can play and launch in < 1-2 sec.
>
> Of course, you could also just create your own bundles that define
> extensions and extension points and lauch using an Equinox launch
> configuration...
>
> Jeff
>
> Toni Menzel wrote:
>> to make things more specic:
>> I try to get familar with the eclipse way of DS: Exensions and
>> ExtensionPoints.
>> So I write a plugin contributing a extension to a ui extensionpoint
>> inside the current worbench (let's say a view for example).
>> So I do not want a new framework instance (either worbench or just
>> equinox), i just want to plugin in my development-effort into my
>> running environment.
>>
>> hope this makes this newsgroupentry more comprehensible..;-)
>> Toni
>>
>> Toni Menzel schrieb:
>>> Hi,
>>>
>>> Coming from an osgi background (I digged inside of apache felix to
>>> get familar with osgi and separate plain osgi concerns from eclipse
>>> stuff)
>>> i wonder about the most obvious way to launch a (small) plugin
>>> written in the PDE: it is, launching a separte Workbench/App with my
>>> (new) plugin inside.
>>> That's 1998!! I think (hope so!!) it is not a limitation of the
>>> platform layer of eclipse (workbench) above osgi requiring my weak G4
>>> powerbook (nice but.. well not that superb fast) to load a new
>>> workbench on each development step..
>>> As I mentioned above coming from the osgi experience, I would assume
>>> a plain bundle-update on just the changed bundle and everything is
>>> fine (things come and go..)
>>>
>>> Is anybody here with some short advice/tips?
>>> To control things, i would appriciate having the equinox-shell
>>> launched inside my PDE and controlling plugins that that way.
>>> However, there must be the osgi way to update things inside the PDE.
>>>
>>> kind regards,
>>> Toni
|
|
|
| Re: Debugging/Testing Plugins, where is the dynmaic behaviour?? [message #78319 is a reply to message #78304] |
Sat, 02 December 2006 11:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Toni Menzel wrote:
> But.. can you (or someone at the newsgroup) explain me why the following
> scenario is not "possible" currently (or at least not well accessable):
>
> - I create a new plugin project, select the view-template to get started
> with a very simple but visible thing.
> - This bundle contributes functionality (here widgets) to the eclipse-ui
> (a new fancy view)
>
> Now: what is the problem in a osgi based mechanism to add the bundle to
> the (already running inside of my development-eclipse-instance) equinox
> container, let it resolve and launch.
Sure this can be done. It is however not a mainline usecase and so is
not directly supported by the tooling.
Small terminology nit, the "launch" part does not happen since you are
already running the Eclipse in which you want to run the bundle you just
created. Really you just have to install and resolve. The rest should
happen for free.
> The servicelayer then should trigger a contribution to the list of
> available views.
Another nit: For the most part Eclipse uses the Extension Registry not
the OSGi Service Registry. This is part historical and part "best fit
to the problem at hand". In any event, the Extension registry will
indeed notice the new contributions and broadcast a registry changed
event that others can listen for and react to.
> I really thought osgi was about not having to "devolve into a gooey mess
> of quivering classes and bytecodes"..
There are several things at play here. The first guiding principle is
"there is no free lunch". Just using OSGi is not a silver bullet (you
started this cliche thing with your forest/trees comment :-) that
suddenly makes everything "dynamic aware". That is, OSGi *enables*
bundles, services, extensions, ... to come and go but it does not force
people to behave properly. You can lead a horse to water but you can't
make it drink!
In this context, whether it is services, extensions or some other
interaction mechanism the interacting parties must *listen* to each
other and *react* according to what they hear. So, your plugin
contributes a view extension. It is contributed to the UI plugin. The
UI plugin has to listen for changes to its extension point. It happens
that the Eclipse UI plugin *is* coded to do this. Not all bundles in
the world (or Eclipse for that matter) are. On the whole this is
analogous to running on a parallel/distributed system. Sure everything
*can* be parallel/distributed but making it work well that way requires
extra effort.
If people in the system being run do not behave well you end up with
- added/changed/removed contributions/services/... not being noticed
- garbage references to defunct objects, classes, class loaders, ...
- inconsistent bindings across multiple versions of bundles that were added
- ...
Note that these issues are not particular to Eclipse. The same things
can happen if you program OSGi services poorly.
> so, does the PDE have so many layers between itself and core osgi that it
No, PDE is right on OSGi/Equinox. The issues it that the main drivers
for its design do not include writing bundles for the system that is
itself running PDE.
> does not "see the forrest because of too much trees"
> (.. german saying, hope you know what I mean)
Yup. In English it shows up as "...can't see the forest for the trees"
Jeff
|
|
|
Goto Forum:
Current Time: Sat May 10 01:25:16 EDT 2025
Powered by FUDForum. Page generated in 0.02620 seconds |
Home