how to write an eclimd client?

[Harald Lapp]

hello,

view days ago i stumbled over this interesting project.

i'm currently looking for a solution of how to integrate better code
completion (or even "intelligent" code completion) for PHP into
textmate. as far as i understand this project, it could be possible to
connect textmate to eclipse for such using eclimd? i would be
interested of how big the effort is in implementing an eclimd client
(in general) and how to get started with this.

many thanks in advance,

harald

[Eric Van Dewoestine]

Writing a client for eclimd is pretty straightforward. The amount of
effort to write one varies greatly depending on how many of the
features you integrate with.

Every command that eclimd exposes can be run on the command line like
so:

$ $ECLIPSE_HOME/eclim -command ping
eclim 1.5.3
eclipse 3.5.1

So invoking commands from any app is as easy as invoking the
appropriate "eclim -command" and parsing the results. If you want to
avoid an external call to the shell you can write a nailgun client for
textmate to invoke the command directly (there is the standard c[1]
client and a user contributed python[2] client that you can use for
reference if you want to go this route).

For help determining the "eclim -command" string, your best bet would
be to install vim, set the following variable in your .vimrc, and then
run the appropriate command in vim to see the command it builds:

let g:EclimLogLevel = 10

Hopefully that gives you an idea of what is involved. If you decide
to pursue this further, please feel free to send questions to this
mailing list and post the link to your project (if/when you create
one). I think senny (Yves Senn) is on this list too, so he can
probably provide some additional insight into his experiences as he
implements an emacs client[3] for eclimd.

[1] http://github.com/ervandew/eclim/blob/master/src/nailgun/src/c/ng.c
[2] http://github.com/ervandew/eclim/blob/master/src/vim/eclim/autoload/eclim/client/python/nailgun.py
[3] http://github.com/senny/emacs-eclim

--
eric

[Harald Lapp]

thanks very much for your help! i'll have a look at it and post a
link, if i decide to really make a textmate bundle for eclim

thanks again,

harald

> [2]http://github.com/ervandew/eclim/blob/master/src/vim/eclim/autoload/e...

[Liam Coughlin]

I'm working on a eclim client as well, and I was curious if any better documentation on what eclim -command strings are available... it would seem having that might be useful rather then each client implementor reverse engineering the server and/or other clients...  I'd even be willing to assist given a little direction.

Cheers,

-liam

[Eric Van Dewoestine]

On 2013-04-29 04:52:40, Liam Coughlin wrote:
> I'm working on a eclim client as well, and I was curious if any better
> documentation on what eclim -command strings are available... it would seem
> having that might be useful rather then each client implementor reverse
> engineering the server and/or other clients... I'd even be willing to
> assist given a little direction.
>
> Cheers,
> -liam

The eclim client now includes some usage output for the currently
enabled commands:

$ eclim -? commands

Is that what you're looking for?

--
eric

[Liam Coughlin]

Yeah, i found that, and it's an awesome start!

But it's still a constant stream of exploration, finding out that -f is relative to a project root sometimes and relative to a source root others, still sort of wondering what java_checkstyle does...

I'm making my way through it, and i'm super grateful that the project exists and with the capabilities it provides... it's just.... my kingdom for good docs :P

[Eric Van Dewoestine]

On 2013-05-01 05:50:39, Liam Coughlin wrote:
> Yeah, i found that, and it's an awesome start!
>
> But it's still a constant stream of exploration, finding out that -f is
> relative to a project root sometimes and relative to a source root others,

Hmm, I can't think of a case where -f would be relative to a source
root. For any command that requires a project arg, the -f should be
relative to that project. For the handful of commands that are project
agnostic (archive_read and xml_format for example), the -f would be
absolute since there is no project argument.

Which command(s) did you encounter where -f is relative to a source
root?

> still sort of wondering what java_checkstyle does...

http://eclim.org/vim/java/validate.html#checkstyle

> I'm making my way through it, and i'm super grateful that the project
> exists and with the capabilities it provides... it's just.... my kingdom
> for good docs :P

From the perspective of someone working on a new eclim client, I can
see how making the connection from a command name (java_checkstyle),
to the implementing class (...jdt.command.src.CheckstyleCommand), to
the user docs (http://eclim.org/vim/java/validate.html#checkstyle) can
be annoying/difficult. Unfortunately all the time I've spent
documenting has been focused on user docs, which themselves suffer
from my single point of view.

Now that you've started digging into this, do you have any suggestions
on what sort of documentation would be most useful? It's not often
that someone writes a new eclim client, so I wouldn't want to write a
book on the subject, but outlining key information I'm sure would
help, and some of that info would probably overlap with info that an
eclim command contributor might need.

> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
eric

[Liam Coughlin]

On Wednesday, May 1, 2013 3:19:30 PM UTC+2, Eric Van Dewoestine wrote:

On 2013-05-01 05:50:39, Liam Coughlin wrote:
> Yeah, i found that, and it's an awesome start!
>
> But it's still a constant stream of exploration, finding out that -f is
> relative to a project root sometimes and relative to a source root others,

Hmm, I can't think of a case where -f would be relative to a source
root. For any command that requires a project arg, the -f should be
relative to that project. For the handful of commands that are project
agnostic (archive_read and xml_format for example), the -f would be
absolute since there is no project argument.

Which command(s) did you encounter where -f is relative to a source
root?

I think I may have mis-spoken there... not the source root, but rather, the project root(?) i guess?  example speaks better one supposes.  

$eclim -command project_list

[{"open":true,"path":"/home/joeblow/Documents/workspace/SomeProject","name":"SomeProject"}]

So this succeeds:

$eclim -command java_complete -p SomeProject -f src/test/Hello.java -o 106 -e utf-8 -l compact

And these render errors:

$eclim -command java_complete -p SomeProject -f test/Hello.java -o 106 -e utf-8 -l compact

$eclim -command java_complete -p SomeProject -f /home/joeblow/Documents/workspace/SomeProject/src/test/Hello.java -o 106 -e utf-8 -l compact

I can see how this makes sense from an eclipse perspective, but from service consuming a client perspective all three are essentially the same thing. 

 

> still sort of wondering what java_checkstyle does...

http://eclim.org/vim/java/validate.html#checkstyle

> I'm making my way through it, and i'm super grateful that the project
> exists and with the capabilities it provides... it's just.... my kingdom
> for good docs :P

From the perspective of someone working on a new eclim client, I can
see how making the connection from a command name (java_checkstyle),
to the implementing class (...jdt.command.src.CheckstyleCommand), to
the user docs (http://eclim.org/vim/java/validate.html#checkstyle) can
be annoying/difficult. Unfortunately all the time I've spent
documenting has been focused on user docs, which themselves suffer
from my single point of view.

No worries at all at all.  Documentation is the part most people despise with a passion and never get around too. I'm psyched to get what i get :P

 

Now that you've started digging into this, do you have any suggestions
on what sort of documentation would be most useful? It's not often
that someone writes a new eclim client, so I wouldn't want to write a
book on the subject, but outlining key information I'm sure would
help, and some of that info would probably overlap with info that an
eclim command contributor might need.

I'm sort of making documentation for myself as i go along:  I attached my entry for java_complete so you can see what i'm doing.

FWIW i am (slowly) building a node.js eclim client to back a codemirror java editor.  Not with any large ambitions, just so i can VPN into my house and code on my tablet from the coffeeshop down the street.

[Eric Van Dewoestine]

Well the second one, test/Hello.java, can be ambiguous if you have
more than one source directory each containing a file of the same
name. Also, not all project types have designated source directories
and some commands work with files outside of source directories, so
having the argument always be project relative makes it consistent and
unambiguous. Remember, eclim is not a java only tool :)

Supporting the absolute path, as in your third example, could probably
be done pretty easily, though I guess I'm slightly reluctant to
support that since it gives the impression that any absolute path can
be supplied there, when in fact the file at that path still must be
within the project. Allowing only a project relative path ensures that
only files found within that project can be referenced as arguments.

> > > still sort of wondering what java_checkstyle does...
> >
> > http://eclim.org/vim/java/validate.html#checkstyle
> >
> > > I'm making my way through it, and i'm super grateful that the project
> > > exists and with the capabilities it provides... it's just.... my kingdom
> > > for good docs :P
> >
> > From the perspective of someone working on a new eclim client, I can
> > see how making the connection from a command name (java_checkstyle),
> > to the implementing class (...jdt.command.src.CheckstyleCommand), to
> > the user docs (http://eclim.org/vim/java/validate.html#checkstyle) can
> > be annoying/difficult. Unfortunately all the time I've spent
> > documenting has been focused on user docs, which themselves suffer
> > from my single point of view.
> >
> >
> No worries at all at all. Documentation is the part most people despise
> with a passion and never get around too. I'm psyched to get what i get :P
>
>
>
> > Now that you've started digging into this, do you have any suggestions
> > on what sort of documentation would be most useful? It's not often
> > that someone writes a new eclim client, so I wouldn't want to write a
> > book on the subject, but outlining key information I'm sure would
> > help, and some of that info would probably overlap with info that an
> > eclim command contributor might need.
> >
> >
> I'm sort of making documentation for myself as i go along: I attached my
> entry for java_complete so you can see what i'm doing.

It would be nice to having something like that in the javadocs for
each command and possibly extract that info using some javadoc
doclets to build a separate reference by command name. I'll add a note
to my todo list to look into that if I can find the time.

> FWIW i am (slowly) building a node.js eclim client to back a codemirror
> java editor. Not with any large ambitions, just so i can VPN into my house
> and code on my tablet from the coffeeshop down the street.

Sounds like a cool project. If you haven't already, you should
consider throwing it up on github or similar. Other people may find it
useful and you never know when someone will come along and run with
it.

> > an email to eclim-dev+...@googlegroups.com <javascript:>.
> > > To post to this group, send email to ecli...@googlegroups.com<javascript:>.

> >
> > > Visit this group at http://groups.google.com/group/eclim-dev?hl=en.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> > >
> >
> > --
> > eric
> >

--
eric