[ https://issues.jboss.org/browse/ERT-623?page=com.atlassian.jira.plugin.sy... ] 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. -- This message was sent by Atlassian JIRA (v7.5.0#75005)