Home » Eclipse Projects » Rich Client Platform (RCP) » Plugin Discovery
| Plugin Discovery [message #398212] |
Mon, 06 December 2004 05:43  |
Eclipse User |
|
|
|
Good morning eclipser's. I've got a trickey question. Maybe one of you
guys have already done something similar. Here is a little bit of a
background on what we're doing. We've written 'n financial RCP application
that will be delivered to different target markets. Thus, we created a
plugin 'workbench', with our different financial components as seperate
plug-ins. I.E. Different quoting engines. Depending on the target market,
we would ship different plug-ins specific to their needs.
Now, my question is: I'd like to communicate between two plug-ins. The
catch is, that not one of the plug-ins should know about each other's
classes. (Very loosley coupled). They should communicate via 'messages'.
The reason for this is, that a plug-in can be shipped without the other,
and if they are shipped together they can provide services to each other.
My idea is sort of a 'publish & subscribe' solution. One plug-in would
anounce that he needs 'List of Clients', and than, if there is a plug-in
available that can provide the service, be able to respond. If there is
none, the service will be disabled...
Wow, that is a mouth full....Hope somebody out there has a couple of ideas
to share with me....
Cheers, and greetings from a cold and wet South Africa.
-Martin Coetzee (www.coetzee-family.com)
|
|
|
| Re: Plugin Discovery [message #398214 is a reply to message #398212] |
Mon, 06 December 2004 09:13  |
| Eclipse User |
|
|
|
Originally posted by: jernej.srebric.gmail.com
Martin Coetzee wrote:
> Good morning eclipser's. I've got a trickey question. Maybe one of you
> guys have already done something similar. Here is a little bit of a
> background on what we're doing. We've written 'n financial RCP
> application that will be delivered to different target markets. Thus, we
> created a plugin 'workbench', with our different financial components as
> seperate plug-ins. I.E. Different quoting engines. Depending on the
> target market, we would ship different plug-ins specific to their needs.
> Now, my question is: I'd like to communicate between two plug-ins. The
> catch is, that not one of the plug-ins should know about each other's
> classes. (Very loosley coupled). They should communicate via 'messages'.
> The reason for this is, that a plug-in can be shipped without the other,
> and if they are shipped together they can provide services to each other.
> My idea is sort of a 'publish & subscribe' solution. One plug-in would
> anounce that he needs 'List of Clients', and than, if there is a plug-in
> available that can provide the service, be able to respond. If there is
> none, the service will be disabled...
>
> Wow, that is a mouth full....Hope somebody out there has a couple of
> ideas to share with me....
>
> Cheers, and greetings from a cold and wet South Africa.
>
> -Martin Coetzee (www.coetzee-family.com)
>
a 3rd plugin shared by your plugins. 3rd provides the commincation...
if someone has a better design ples report.
|
|
|
| Re: Plugin Discovery [message #398216 is a reply to message #398212] |
Mon, 06 December 2004 09:35 |
| Eclipse User |
|
|
|
On Mon, 06 Dec 2004 10:43:45 +0000, Martin Coetzee wrote:
> Good morning eclipser's. I've got a trickey question. Maybe one of you
> guys have already done something similar. Here is a little bit of a
> background on what we're doing. We've written 'n financial RCP application
> that will be delivered to different target markets. Thus, we created a
> plugin 'workbench', with our different financial components as seperate
> plug-ins. I.E. Different quoting engines. Depending on the target market,
> we would ship different plug-ins specific to their needs.
>
> Now, my question is: I'd like to communicate between two plug-ins. The
> catch is, that not one of the plug-ins should know about each other's
> classes. (Very loosley coupled). They should communicate via 'messages'.
> The reason for this is, that a plug-in can be shipped without the other,
> and if they are shipped together they can provide services to each other.
>
> My idea is sort of a 'publish & subscribe' solution. One plug-in would
> anounce that he needs 'List of Clients', and than, if there is a plug-in
> available that can provide the service, be able to respond. If there is
> none, the service will be disabled...
>
> Wow, that is a mouth full....Hope somebody out there has a couple of ideas
> to share with me....
>
> Cheers, and greetings from a cold and wet South Africa.
>
> -Martin Coetzee (www.coetzee-family.com)
We have a similar situation in our RCP workbench application. For example,
we have 3 plug-ins that define a tree-view, a table-view, and a
perspective which arranges those 2 views as an ordinary file explorer. We
loosly coupled those 2 communicating view plug-ins by adding an extra
controller plug-in which manages the communication between the tree-view
plug-in and the table-plugin or any other plug-in which registers himself
to the controller plug-in as listeners and/or speaker. Of course, we added
a "listener" and "speaker" extension point (with the necessary interfaces
to be implemented by extender plug-ins) to the controller plug-in. In that
way, it seems that the tree-view and table-view are directly communicating
with each other, but the communication goes via the controller plug-in.
Hope this helps you a little bit further...
|
|
|
| Re: Plugin Discovery [message #398222 is a reply to message #398212] |
Mon, 06 December 2004 12:36 |
| Eclipse User |
|
|
|
"Martin Coetzee" <mcoetzee@fnbinsurance.co.za> wrote in message
news:cp1d50$6la$1@www.eclipse.org...
> Good morning eclipser's. I've got a trickey question. Maybe one of you
> guys have already done something similar. Here is a little bit of a
> background on what we're doing. We've written 'n financial RCP application
> that will be delivered to different target markets. Thus, we created a
> plugin 'workbench', with our different financial components as seperate
> plug-ins. I.E. Different quoting engines. Depending on the target market,
> we would ship different plug-ins specific to their needs.
> Now, my question is: I'd like to communicate between two plug-ins. The
> catch is, that not one of the plug-ins should know about each other's
> classes. (Very loosley coupled). They should communicate via 'messages'.
> The reason for this is, that a plug-in can be shipped without the other,
> and if they are shipped together they can provide services to each other.
> My idea is sort of a 'publish & subscribe' solution. One plug-in would
> anounce that he needs 'List of Clients', and than, if there is a plug-in
> available that can provide the service, be able to respond. If there is
> none, the service will be disabled...
>
> Wow, that is a mouth full....Hope somebody out there has a couple of ideas
> to share with me....
>
I would suggest looking into was the OSGi layer in Eclipse can do for you
here. OSGi provides the ability for a plugin (called a 'bundle' in the OSGi
world) to register a service and for other plugins to lookup a service.
Also a plugin can have a service 'activator' that is responsible for
starting services when the plugin is started. A service must implement an
interface and that service is looked up by the interface that it implements.
So, you could define a service interface named something like
my.IClientLister. Your first plugin would, if available, register this
service when it is started. Your other plugin would look up
my.IClientLister when it starts up and, if my.IClientLister is available,
would register all services that require my.IClientLister. If
my.IClientLister is not available then the 2nd plugin would not register any
of the services that require my.IClientLister.
OSGi publishes a complete specification that coveres everything that you
need to know. http://www.osgi.org.
>
> Cheers, and greetings from a cold and wet South Africa.
>
I live in Chicago IL, USA. I don't think you know what cold and wet really
is ;-)...
|
|
|
| Re: Plugin Discovery [message #398241 is a reply to message #398222] |
Tue, 07 December 2004 00:48 |
| Eclipse User |
|
|
|
Good morning Ted. Thanx for the reply. This is what I'm looking for. I
will read up on the how the osgi layer function, and how it's positioned
inside eclipse.
Thanx for all the help!
Cheers, Martin
ted stockwell wrote:
> "Martin Coetzee" <mcoetzee@fnbinsurance.co.za> wrote in message
> news:cp1d50$6la$1@www.eclipse.org...
>> Good morning eclipser's. I've got a trickey question. Maybe one of you
>> guys have already done something similar. Here is a little bit of a
>> background on what we're doing. We've written 'n financial RCP application
>> that will be delivered to different target markets. Thus, we created a
>> plugin 'workbench', with our different financial components as seperate
>> plug-ins. I.E. Different quoting engines. Depending on the target market,
>> we would ship different plug-ins specific to their needs.
>> Now, my question is: I'd like to communicate between two plug-ins. The
>> catch is, that not one of the plug-ins should know about each other's
>> classes. (Very loosley coupled). They should communicate via 'messages'.
>> The reason for this is, that a plug-in can be shipped without the other,
>> and if they are shipped together they can provide services to each other.
>> My idea is sort of a 'publish & subscribe' solution. One plug-in would
>> anounce that he needs 'List of Clients', and than, if there is a plug-in
>> available that can provide the service, be able to respond. If there is
>> none, the service will be disabled...
>>
>> Wow, that is a mouth full....Hope somebody out there has a couple of ideas
>> to share with me....
>>
> I would suggest looking into was the OSGi layer in Eclipse can do for you
> here. OSGi provides the ability for a plugin (called a 'bundle' in the OSGi
> world) to register a service and for other plugins to lookup a service.
> Also a plugin can have a service 'activator' that is responsible for
> starting services when the plugin is started. A service must implement an
> interface and that service is looked up by the interface that it implements.
> So, you could define a service interface named something like
> my.IClientLister. Your first plugin would, if available, register this
> service when it is started. Your other plugin would look up
> my.IClientLister when it starts up and, if my.IClientLister is available,
> would register all services that require my.IClientLister. If
> my.IClientLister is not available then the 2nd plugin would not register any
> of the services that require my.IClientLister.
> OSGi publishes a complete specification that coveres everything that you
> need to know. http://www.osgi.org.
>>
>> Cheers, and greetings from a cold and wet South Africa.
>>
> I live in Chicago IL, USA. I don't think you know what cold and wet really
> is ;-)...
|
|
| | |
| Re: Plugin Discovery [message #398265 is a reply to message #398212] |
Tue, 07 December 2004 17:39 |
| Eclipse User |
|
|
|
I see you have a couple of good ideas already. What about using regular
extension points? One plug-in declares an extension point to recieve, in
your example, a list of clients. Part of that extension point would be a
definition of one or more interfaces. The second (up to n actually)
plug-in provides for that extension and implements the required interfaces.
If the plug-in providing the extension point does not have any plug-ins
that supply the provide for that extension then it would simply disable
the appropriate features.
I am not sure how this fits with the OSGI services stuff (probably in 3.0
extension points have been reimplemented using services) but extension
points have been around in Eclise for a long time.
Ian
(From cold with freezing rain Ottawa)
Martin Coetzee wrote:
> Good morning eclipser's. I've got a trickey question. Maybe one of you
> guys have already done something similar. Here is a little bit of a
> background on what we're doing. We've written 'n financial RCP application
> that will be delivered to different target markets. Thus, we created a
> plugin 'workbench', with our different financial components as seperate
> plug-ins. I.E. Different quoting engines. Depending on the target market,
> we would ship different plug-ins specific to their needs.
> Now, my question is: I'd like to communicate between two plug-ins. The
> catch is, that not one of the plug-ins should know about each other's
> classes. (Very loosley coupled). They should communicate via 'messages'.
> The reason for this is, that a plug-in can be shipped without the other,
> and if they are shipped together they can provide services to each other.
> My idea is sort of a 'publish & subscribe' solution. One plug-in would
> anounce that he needs 'List of Clients', and than, if there is a plug-in
> available that can provide the service, be able to respond. If there is
> none, the service will be disabled...
> Wow, that is a mouth full....Hope somebody out there has a couple of ideas
> to share with me....
> Cheers, and greetings from a cold and wet South Africa.
> -Martin Coetzee (www.coetzee-family.com)
|
|
|
| Re: Plugin Discovery [message #398270 is a reply to message #398265] |
Wed, 08 December 2004 00:34 |
| Eclipse User |
|
|
|
Extension/ Extension points and services are really two orthogonal
concepts. The main difference is that extension / extension point are
purely declarative whereas service registration is programmatic and
require the activation of the bundle providing the service (in osgi
bundles are started eargerly by an "administrator").
Another notable difference is that extension / extension point provides
extensibility (you add a new menu entry), whereas services provide
replaceability (you provide a new code formatter implementation
conforming to an interface).
PaScaL
(From the same Ottawa freezing rain - probably the worst thing IMO)
Ian Leslie wrote:
> I see you have a couple of good ideas already. What about using regular
> extension points? One plug-in declares an extension point to recieve,
> in your example, a list of clients. Part of that extension point would
> be a definition of one or more interfaces. The second (up to n
> actually) plug-in provides for that extension and implements the
> required interfaces.
>
> If the plug-in providing the extension point does not have any plug-ins
> that supply the provide for that extension then it would simply disable
> the appropriate features.
>
> I am not sure how this fits with the OSGI services stuff (probably in
> 3.0 extension points have been reimplemented using services) but
> extension points have been around in Eclise for a long time.
>
> Ian
> (From cold with freezing rain Ottawa)
>
> Martin Coetzee wrote:
>
>> Good morning eclipser's. I've got a trickey question. Maybe one of you
>> guys have already done something similar. Here is a little bit of a
>> background on what we're doing. We've written 'n financial RCP
>> application that will be delivered to different target markets. Thus,
>> we created a plugin 'workbench', with our different financial
>> components as seperate plug-ins. I.E. Different quoting engines.
>> Depending on the target market, we would ship different plug-ins
>> specific to their needs.
>
>
>> Now, my question is: I'd like to communicate between two plug-ins. The
>> catch is, that not one of the plug-ins should know about each other's
>> classes. (Very loosley coupled). They should communicate via
>> 'messages'. The reason for this is, that a plug-in can be shipped
>> without the other, and if they are shipped together they can provide
>> services to each other.
>
>
>> My idea is sort of a 'publish & subscribe' solution. One plug-in would
>> anounce that he needs 'List of Clients', and than, if there is a
>> plug-in available that can provide the service, be able to respond. If
>> there is none, the service will be disabled...
>
>
>> Wow, that is a mouth full....Hope somebody out there has a couple of
>> ideas to share with me....
>
>
>> Cheers, and greetings from a cold and wet South Africa.
>
>
>> -Martin Coetzee (www.coetzee-family.com)
>
>
>
|
|
|
Goto Forum:
Current Time: Sat Nov 08 14:52:09 EST 2025
Powered by FUDForum. Page generated in 0.04807 seconds |
Home