How does it communicate with eclipse?

82 views
Skip to first unread message

philip

unread,
Sep 5, 2009, 7:02:52 AM9/5/09
to eclim-dev
Hi,

How does this program communicate with Eclipse, is it because it runs
in the same VM as Eclipse (using nailgun) it just calls Eclipse API's
directly?
I am interested to make my own IDE in Adobe FLEX communiciating with
Eclipse.

Thanks, Philip

Eric Van Dewoestine

unread,
Sep 5, 2009, 2:30:47 PM9/5/09
to ecli...@googlegroups.com
On Sat, Sep 5, 2009 at 4:02 AM, philip <phili...@gmail.com> wrote:
>
> Hi,
>
> How does this program communicate with Eclipse, is it because it runs
> in the same VM as Eclipse (using nailgun) it just calls Eclipse API's
> directly?

When running gvim embedded in the eclipse gui there is a bit of
communication over vim's netbeans protocol, but the vast majority of
the communication (all of it actually in eclim's headless mode) is
performed via nailgun. So, all of eclim's java code is running in the
same vm as the rest of eclipse.

> I am interested to make my own IDE in Adobe FLEX communiciating with
> Eclipse.

If you want to, you could actually leverage all of the eclipse
features that eclim current exposes in your IDE. All of the commands
implemented in the running eclim daemon are editor agnostic. When I
started the project I made a concious effort to keep the code running
in vim decoupled from the eclipse features exposes in the eclim
daemon, that way any program can interact with the eclim daemon. All
of the eclim commands simply print their results to stdout in a plain
text format, so you can run them in a shell to examine the output:

$ /usr/local/java/eclipse/eclim -command ping
eclim 1.5.2.4-g77b4eb8
eclipse 3.5.0

$ $ /usr/local/java/eclipse/eclim -command java_search -n eclim -p "Command"
/home/ervandew/files/development/java/eclim/src/java/org/eclim/annotation/Command.java|31
col 19|org.eclim.annotation.Command
/home/ervandew/files/development/java/eclim/src/java/org/eclim/command/Command.java|26
col 18|org.eclim.command.Command
...

You could also easily write a nailgun client in action script
alleviating the need to make a system call. A user contributed a
python client[1] which could serve as a good example should you want
to go that route.

If you decide that you would prefer to write your own integration with
eclipse instead of leveraging eclim, feel free to send me questions.
Writing a headless daemon for eclipse poses some difficulties that
took me a while of digging around eclipse code to work around, so if
you get stuck I can probably point you in the right direction.

[1] http://eclim.git.sourceforge.net/git/gitweb.cgi?p=eclim/eclim;a=blob_plain;f=src/vim/eclim/autoload/eclim/client/python/nailgun.py;hb=HEAD

--
eric

philip

unread,
Sep 6, 2009, 11:59:39 PM9/6/09
to eclim-dev
Hi Eric,

Wow thanks for all the information.

In terms of architecture, what I plan to do is have the FLEX client
talk to a JBoss server via GraniteDS, the JBoss server would run SEAM
components (EJB components) which then talks to your "eclim daemon"
via nailgun.
I choose this as my JBoss server needs to provide other functions, not
just the Eclipse ones to support my IDE. For example, communication
between developers, edited files are kept on the server side, not on
the client side.
What do you think of this choice of architecture?

Your "eclim daemon" runs in Eclipse with Eclipse in headless mode?
Well I will look and find out, I guess thats true. Then all I need to
do is call your classes via nailgun from my JBoss server. I wonder if
JBoss will be happy to work within Nailgun running JVM.

Philip

On 9月6日, 上午2時30分, Eric Van Dewoestine <ervan...@gmail.com> wrote:
> On Sat, Sep 5, 2009 at 4:02 AM, philip <philip14...@gmail.com> wrote:
>
> > Hi,
>
> > How does this program communicate with Eclipse, is it because it runs
> > in the same VM as Eclipse (using nailgun) it just calls Eclipse API's
> > directly?
>
> When running gvim embedded in the eclipse gui there is a bit of
> communication over vim's netbeans protocol, but the vast majority of
> the communication (all of it actually in eclim's headless mode) is
> performed via nailgun.  So, all of eclim's java code is running in the
> same vm as the rest of eclipse.
>
> > I am interested to make my own IDE in Adobe FLEX communiciating with
> > Eclipse.
>
> If you want to, you could actually leverage all of the eclipse
> features that eclim current exposes in your IDE.  All of the commands
> implemented in the running eclim daemon are editor agnostic.  When I
> started the project I made a concious effort to keep the code running
> in vim decoupled from the eclipse features exposes in the eclim
> daemon, that way any program can interact with the eclim daemon.  All
> of the eclim commands simply print their results to stdout in a plain
> text format, so you can run them in a shell to examine the output:
>
> $ /usr/local/java/eclipse/eclim -command ping
> eclim   1.5.2.4-g77b4eb8
> eclipse 3.5.0
>
> $ $ /usr/local/java/eclipse/eclim -command java_search -n eclim -p "Command"
> /home/ervandew/files/development/java/eclim/src/java/org/eclim/annotation/C­ommand.java|31
> col 19|org.eclim.annotation.Command
> /home/ervandew/files/development/java/eclim/src/java/org/eclim/command/Comm­and.java|26
> col 18|org.eclim.command.Command
> ...
>
> You could also easily write a nailgun client in action script
> alleviating the need to make a system call.  A user contributed a
> python client[1] which could serve as a good example should you want
> to go that route.
>
> If you decide that you would prefer to write your own integration with
> eclipse instead of leveraging eclim, feel free to send me questions.
> Writing a headless daemon for eclipse poses some difficulties that
> took me a while of digging around eclipse code to work around, so if
> you get stuck I can probably point you in the right direction.
>
> [1]http://eclim.git.sourceforge.net/git/gitweb.cgi?p=eclim/eclim;a=blob_...
>
> --
> eric

Eric Van Dewoestine

unread,
Sep 7, 2009, 1:22:03 AM9/7/09
to ecli...@googlegroups.com
On Sun, Sep 6, 2009 at 8:59 PM, philip <phili...@gmail.com> wrote:
>
> Hi Eric,
>
> Wow thanks for all the information.
>
> In terms of architecture, what I plan to do is have the FLEX client
> talk to a JBoss server via GraniteDS, the JBoss server would run SEAM
> components (EJB components) which then talks to your "eclim daemon"
> via nailgun.
> I choose this as my JBoss server needs to provide other functions, not
> just the Eclipse ones to support my IDE. For example, communication
> between developers, edited files are kept on the server side, not on
> the client side.
> What do you think of this choice of architecture?

That sounds like a very promising project. Adding collaborative
editing features and integrating code reviews would be very cool as
well.

> Your "eclim daemon" runs in Eclipse with Eclipse in headless mode?

Correct. Unfortunately though, even in a headless mode, eclipse still
requires access to X libraries and a running display. However, though
I haven't tested it, eclipse should be able to run with xvfb so you
should be able to still run it on a truly headless server.

> Well I will look and find out, I guess thats true. Then all I need to
> do is call your classes via nailgun from my JBoss server. I wonder if
> JBoss will be happy to work within Nailgun running JVM.

You can probably run jboss inside of eclipse, perhaps installed as an
osgi bundle. Installing JBossTools[1] (developer studio I believe)
should take care of this for you, hopefully allowing you to simply
deploy your seam app into it. Then you can probably call the eclim
Main class directly. I'm sure there will be some class loader issues
you'll have to work around, but if all else fails, a custom class
loader will probably get you around those.

You may have to watch out for concurrency issues when allowing two or
more users access to the same eclipse instance. It would probably be
a good idea to prototype some of those scenarios. If the eclipse core
can't handle it, then that would be a major issue. The eclim code
should be thread safe since, aside from a couple exceptions, I don't
think it maintains any kind of mutable global state. The couple
exceptions to that should be easy enough to update to using thread
locals.

Another multi user issue you would need to consider, is project
management. Since eclipse is design for a single user, you'd probably
need some sort of user based naming convention to prevent project
names from overlapping.

[1] http://www.jboss.org/tools
--
eric

Reply all
Reply to author
Forward
0 new messages