38 lines
1.2 KiB
Plaintext
38 lines
1.2 KiB
Plaintext
|
*development-architecture*
|
||
|
|
|
||
|
|
|
||
|
|
Eclim Architecture
|
||
|
|
******************
|
||
|
|
|
||
|
|
The eclim architecture is pretty straight forward. Commands issued by
|
||
|
|
a user in vim are relayed via nailgun
|
||
|
|
(http://www.martiansoftware.com/nailgun/) to the running eclim daemon
|
||
|
|
and the proper command implementation is then located and executed.
|
||
|
|
|
||
|
|
Here is a diagram showing the sequence in a bit more detail:
|
||
|
|
|
||
|
|
[image]
|
||
|
|
|
||
|
|
The commands which are executed on the eclimd side are also fairly
|
||
|
|
simply. They accept an object containing the command line parameters
|
||
|
|
passed into the eclimd invocation and then return a string
|
||
|
|
representing the output. Below is a simple class diagram showing the
|
||
|
|
hierarchy of a couple typical commands.
|
||
|
|
|
||
|
|
[image]
|
||
|
|
|
||
|
|
Another important aspect of eclim's architecture is support for
|
||
|
|
plugins. Plugins for eclim are bundled as eclipse plugins with their
|
||
|
|
auto start attribute set to false. When the eclim daemon starts it
|
||
|
|
will locate and load any eclipse plugin with an 'org.eclim.' prefix.
|
||
|
|
|
||
|
|
When a plugin is loaded, eclim will locate the plugin's required
|
||
|
|
resources provider and invoke its initialize method which will then
|
||
|
|
inject its resources (messages, command options, etc) into eclim and
|
||
|
|
register any new commands.
|
||
|
|
|
||
|
|
Here is graphical representation of this process:
|
||
|
|
|
||
|
|
[image]
|
||
|
|
|
||
|
|
vim:ft=eclimhelp
|