[jbosstools-issues] [JBoss JIRA] (ERT-623) Evaluate combination of Docker images of LS (from Che?) with LSP4E

[Mickael Istria (JIRA)]

     [ https://issues.jboss.org/browse/ERT-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mickael Istria resolved ERT-623.
--------------------------------
    Resolution: Done


Done.
See link for demo http://www.screencast.com/t/vksX3uZm1aj

As for the immediate effect, working on this demo has generated:
* new feature and improved UX in DockerTools (Thanks a lot to Jeff and Roland for their assistance in fixing Docker Tools to make this demo work)
* bug reports and some fixes in LSP4E
* bug reports to LSP4J: https://github.com/eclipse/lsp4j/issues/192
* Discussion with LSPHub: https://dev.eclipse.org/mhonarc/lists/lsphub-dev/
* relevant enhancement request to LSP spec: https://github.com/Microsoft/language-server-protocol/issues/483

About restrictions:
* It should be noted that relying on Docker on a workstation is a bad idea. It take a lot of hard drive, it's slower, than a regular process. Moreover, I bet most users of Eclipse IDE actually don't have docker daemon started to have this approach viable for this majority of users.
* Just a LS in Eclipse IDE seem too little. User will also want syntax highlighting as much as LS, so the flow of dynamically adding support of languages in Eclipse IDE needs to also take TextMate into account (but it's already partially covered in tm4e).
* Again, we're all talking about edition, which is just the 2nd step of the typical 4 steps process (provision/import, edit, run, deploy).

If we want to keep digging on this topic:
* Next would be the discovery of Language Server and TextMate grammars. I already have an issue and some proposals described to dynamically discover and install TextMate grammar from GitHub; and I think a similar thing could be done with Language Servers as docker image from DockerHub. I think the proposal of LSPHub is overkill and that if we want Docker containers for LS, it's never going to be as successful as DockerHub can be. But DockerHub search engine sucks too much to be usable so far (seems to miss a perfect match research to look for specific tags).
* Make LS Docker Image assume that entry point starts the LS without any option. So each client can add the option they want without tweaking the entry point. If we can standardize options as proposed in https://github.com/Microsoft/language-server-protocol/issues/483 , then it becomes quite easy to automate configuration with almost no extra-metadata.

> Evaluate combination of Docker images of LS (from Che?) with LSP4E
> ------------------------------------------------------------------
>
>                 Key: ERT-623
>                 URL: https://issues.jboss.org/browse/ERT-623
>             Project: Eclipse Release Train
>          Issue Type: Enhancement
>            Reporter: Mickael Istria
>            Assignee: Mickael Istria
>
> LSP4E offers a way to dynamically associate a Launch configuration representing a language server (communicating over stdio) with a content type to enable LS-based edition assistance in editor.
> It would be interesting to try this using a Docker Launch Configuration with LSP4E, more particularly, it'd be nice to test the Docker LS images that are created for Eclipse Che.
> cc [~rgrunber] : any obvious concern about it?
> cc [~flbe] : are the image for Language Server in Che streaming the LS messages over stdio? Or is it using another channel?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)