> As far i know, in Irida classloader you can define depended plugins. > So, then it done, you can use open api of other plugin and attach listeners.
I'm not sure it would work for what I have in mind (but I could be wrong, as I've never touched what you're talking about). The way I see it, "listenedTo" plugins would need to - publish the list of accessible actions/events, and - give access to those actions, through generic listeners.
Example: the TDDplugin. - I'm writing a little SoundAndVoicePlugin, to have IDEA tell me (sound or voice) when the TDDplugin button turns from green to orange, or orange to green. - Somebody else could write another plugin - ex: StatsCollectorPlugin -, to listen to the same events of the same plugin, but for a different purpose. There is no dependency at all here, just optional means of communication. I could be wrong though.
AR> The way I see it, "listenedTo" plugins would need to AR> - publish the list of accessible actions/events, and AR> - give access to those actions, through generic listeners. AR> Example: the TDDplugin. AR> - I'm writing a little SoundAndVoicePlugin, to have IDEA tell me AR> (sound AR> or voice) when the TDDplugin button turns from green to orange, or AR> orange to green.
I think, that TDD plugin must have api for such listening? I'm wrong? Then you may say in plugin.xml that your plugin is depends on TDD plugin version N. IDEA look that dependencies for your plugin and share classes from TDD plugin to access from your plugin. In your plugin, you will invoke TDDListener.addListener(yourPluginListener).
(Sorry for the length of this message, but it has to be long. You may wish to print it)
> I think, that TDD plugin ..
It was just an example, to illustrate the communication, and reuse need. Any plugin should/could be listened to, at a low cost for its author.
> I think, that TDD plugin must have api for such listening? I'm wrong? > Then you may say in plugin.xml that your plugin is depends on TDD plugin version N.
That wouldn't work very well: you'd have to update your listening plugin each time you would want to listen to a new plugin, or each time such a plugin would change (publish a new event)
What I have in mind is much more dynamic, and more "auto-discovery" oriented. => it could be used as well programmatically, as declaratively (see below)
programmatic usage example: -
example: print a message every hour: -
It requires 1 plugin: the AlarmClockPlugin.
myHourMonitorListener = new Listener (){ public action (Object event) { System.err.println ("another hour has passed"); } }
PluginListenersRepository . for ("AlarmClockplugin") .addListenerFor("anotherHourEvent", myTimeOverlistener);
declarative usage example: -
As strings are used to represent all the published info to all the events emitters, and to all their events, and all their actions, ==> you can decide to use it, and what to do with it, at runtime. ====> you can build, or rather assemble, new plugins dynamically, through a visual editor, without writing a single line of code. (Let's call them dyna-plugins).
Note: IDEA would of course its interface accessible like in the example above (through strings selections)
Note: plugin can publish - events, that can be listened to (Ex: projectCommitPerformed, emailSent, alarmTriggered) - actions, that they can perform (Ex: sendEmail, triggerAlarm, commitProject) Note: the actions can have string parameters (see below)
******************************************************************************** example : create a dyna-plugin that sends an email to the CVS manager , each time you commit the project ********************************************************************************
This would require - IDEA to publish its VCS events, the same way I suggested above that plugins would publish their public events. - an EmailSenderPlugin, to send a text message, and - a visual editor, to create the logic (workflow) of the dyna-plugin. Let's call it the "DynaPluginsEditor" (it's a plugin, of course.)
step 0: -
call the DynaPluginEditor + select "New"
=> 1/ a blank area appears, where you will assemble your dyna-plugin It looks like a basic drawing program, that would only let you draw rectangles and straight lines.
A rectangle will represent - any of the plugins that have published their interface, or - IDEA, because it would also pubish its interface this way
step 1: -
Drag 2 rectangles on the blank surface, and position them side to side, with some space between them.
rectangle 1 = IDEA rectangle 2 = the EmailSenderPlugin
each rectangle has : - a left plug :'input', == its triggerable actions (ex. 'sendEmail', for the EmailPlugin rectange)
- a right plug :'output', == its listenableTo events (ex. VcsCommitPerformed, for the IDEA rectangle)
step 2: join IDEA.output -
> input.EmailSenderPlugin -
graphically, you draw the shortest line between the 2 rectanges, and connect it to their plugs.
step 3: specify IDEA.output -
****** - click on the left rectangle (IDEA) 'output' plug ==> a list of all the listenable events appear =====> select "CVSprojectCommit"
step 4: specify input.EmailSenderPlugin -
****** - click on the right rectangle 'input' plug ==> a list of all the actions offered by the EmailSenderPlugin appears =====> select "sendEmail"
each available action (--> method call) published by a plugin, has a list of string properties (--> method parameters)
In this case, you would specify the recipient address, and a short message text.
step 5: -
- press "save this dyna-plugin" - press "load this dyna-plugin"
In the background, a listener for IDEA.VcsCommitPerformed is created, and added to the EmailSenderPlugin 'sendEmail' action.
We're developing new plugin system right away which will allow to define extension points/extensions (somewhat similar to what eclipse has). Seems like your ideas would be feasible to implement there.
Alain Ravet wrote:
Nope for the moment. Coming really soon.
--
Maxim Shafirov
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Alain,
AR> Is there an official (openAPI) way for plugins to communicate.
As far i know, in Irida classloader you can define depended plugins. So,
then it done, you can use open api of other plugin and attach listeners.
Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru
Alexey,
> As far i know, in Irida classloader you can define depended plugins.
> So, then it done, you can use open api of other plugin and attach
listeners.
I'm not sure it would work for what I have in mind (but I could be
wrong, as I've never touched what you're talking about).
The way I see it, "listenedTo" plugins would need to
- publish the list of accessible actions/events, and
- give access to those actions, through generic listeners.
Example: the TDDplugin.
- I'm writing a little SoundAndVoicePlugin, to have IDEA tell me (sound
or voice) when the TDDplugin button turns from green to orange, or
orange to green.
- Somebody else could write another plugin - ex: StatsCollectorPlugin -,
to listen to the same events of the same plugin, but for a different
purpose.
There is no dependency at all here, just optional means of
communication. I could be wrong though.
Alain
Hello Alain,
AR> The way I see it, "listenedTo" plugins would need to
AR> - publish the list of accessible actions/events, and
AR> - give access to those actions, through generic listeners.
AR> Example: the TDDplugin.
AR> - I'm writing a little SoundAndVoicePlugin, to have IDEA tell me
AR> (sound
AR> or voice) when the TDDplugin button turns from green to orange, or
AR> orange to green.
I think, that TDD plugin must have api for such listening? I'm wrong?
Then you may say in plugin.xml that your plugin is depends on TDD plugin
version N.
IDEA look that dependencies for your plugin and share classes from TDD plugin
to access from your plugin.
In your plugin, you will invoke TDDListener.addListener(yourPluginListener).
Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru
Alexey
(Sorry for the length of this message, but it has to be long. You may
wish to print it)
> I think, that TDD plugin ..
It was just an example, to illustrate the communication, and reuse need.
Any plugin should/could be listened to, at a low cost for its author.
> I think, that TDD plugin must have api for such listening? I'm wrong?
> Then you may say in plugin.xml that your plugin is depends on TDD
plugin version N.
That wouldn't work very well: you'd have to update your listening plugin
each time you would want to listen to a new plugin, or each time such a
plugin would change (publish a new event)
What I have in mind is much more dynamic, and more "auto-discovery"
oriented.
=> it could be used as well programmatically, as declaratively (see below)
programmatic usage example:
-
example: print a message every hour:
-
It requires 1 plugin: the AlarmClockPlugin.
myHourMonitorListener = new Listener (){
public action (Object event) {
System.err.println ("another hour has passed");
}
}
PluginListenersRepository
. for ("AlarmClockplugin")
.addListenerFor("anotherHourEvent", myTimeOverlistener);
declarative usage example:
-
As strings are used to represent all the published info to all the
events emitters, and to all their events, and all their actions,
==> you can decide to use it, and what to do with it, at runtime.
====> you can build, or rather assemble, new plugins dynamically,
through a visual editor, without writing a single line of code. (Let's
call them dyna-plugins).
Note: IDEA would of course its interface accessible like in the example
above (through strings selections)
Note: plugin can publish
- events, that can be listened to
(Ex: projectCommitPerformed, emailSent, alarmTriggered)
- actions, that they can perform
(Ex: sendEmail, triggerAlarm, commitProject)
Note: the actions can have string parameters (see below)
********************************************************************************
example : create a dyna-plugin that sends an email to the CVS manager
, each time you commit the project
********************************************************************************
This would require
- IDEA to publish its VCS events, the same way I suggested above that
plugins would publish their public events.
- an EmailSenderPlugin, to send a text message,
and
- a visual editor, to create the logic (workflow) of the dyna-plugin.
Let's call it the "DynaPluginsEditor"
(it's a plugin, of course.)
step 0:
-
call the DynaPluginEditor + select "New"
=> 1/ a blank area appears, where you will assemble your dyna-plugin
It looks like a basic drawing program, that would only let you draw
rectangles and straight lines.
A rectangle will represent
- any of the plugins that have published their interface,
or
- IDEA, because it would also pubish its interface this way
step 1:
-
Drag 2 rectangles on the blank surface, and position them side to side,
with some space between them.
rectangle 1 = IDEA
rectangle 2 = the EmailSenderPlugin
each rectangle has :
- a left plug :'input', == its triggerable actions
(ex. 'sendEmail', for the EmailPlugin rectange)
- a right plug :'output', == its listenableTo events
(ex. VcsCommitPerformed, for the IDEA rectangle)
step 2: join IDEA.output -
> input.EmailSenderPlugin
-
graphically, you draw the shortest line between the 2 rectanges, and
connect it to their plugs.
step 3: specify IDEA.output
-
******
- click on the left rectangle (IDEA) 'output' plug
==> a list of all the listenable events appear
=====> select "CVSprojectCommit"
step 4: specify input.EmailSenderPlugin
-
******
- click on the right rectangle 'input' plug
==> a list of all the actions offered by the EmailSenderPlugin appears
=====> select "sendEmail"
each available action (--> method call) published by a plugin, has a
list of string properties (--> method parameters)
In this case, you would specify the recipient address, and a short
message text.
step 5:
-
- press "save this dyna-plugin"
- press "load this dyna-plugin"
In the background, a listener for IDEA.VcsCommitPerformed is created,
and added to the EmailSenderPlugin 'sendEmail' action.
That's it.
Alain
JB, any comment about this idea?
Alain
Alain,
We're developing new plugin system right away which will allow to define
extension points/extensions (somewhat similar to what eclipse has). Seems
like your ideas would be feasible to implement there.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Maxim
Any news on that matter?
Alain
Kind of sounds like what Hivemind aims to do. It was used the eclipse mechanism for inspiration.