Community
Participate
Working Groups
In order to take advantage of some very nice features provided by VSCode language service ( https://github.com/Microsoft/vscode-languageserver-protocol ) such as completion proposal computers and linters, it would be good to have a common API at Eclipse.org adopters can rely on. I put this in Platform Text at the moment, but it's not really the responsibility of Platform Text project to provide such API. Feel free to move it to a better place. XText folks already implemented the "protocol" part of language service in Java: https://github.com/TypeFox/ls-api Some ongoing work at https://github.com/eclipselabs/eclipse-language-service aims at designing such an API to contribute behavior to existing Eclipse editors using the VSCode lanaguage server.
You could piggyback this CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11516
> VSCode language For Eclipse it is important that this become EPL. Otherwise we might have to create a fork as soon as we need more features.
Why can't we consume MIT licensed information? Isn't that compatible with EPL? Also note that the concrete code I reference in comment #1 is licensed under EPL.
(In reply to Sven Efftinge from comment #3) > Why can't we consume MIT licensed information? Isn't that compatible with > EPL? I'm not a lawyer. AFAIK it would allow a fork. More interesting would be to actually have the protocol in an Eclipse project.
Repo https://github.com/eclipselabs/eclipse-language-service/blob/master/org.eclipse.languageserver/src/org/eclipse/languageserver/LSContentAssistProcessor.java shows a draft example of how to retrieve completion for CSS files from VSCode.
(In reply to Sven Efftinge from comment #3) > Why can't we consume MIT licensed information? Isn't that compatible with > EPL? > Also note that the concrete code I reference in comment #1 is licensed under > EPL. From my experience, the issue is most likely not the project license and the Eclipse IP process but company rules/policies. Employers know Eclipse and most likely employees have a general go to contribute to Eclipse projects. However, if the project is external then it might require another round of legal reviews and approvals.
(In reply to Gunnar Wagenknecht from comment #6) > (In reply to Sven Efftinge from comment #3) > > Why can't we consume MIT licensed information? Isn't that compatible with > > EPL? > > Also note that the concrete code I reference in comment #1 is licensed under > > EPL. > > From my experience, the issue is most likely not the project license and the > Eclipse IP process but company rules/policies. Employers know Eclipse and > most likely employees have a general go to contribute to Eclipse projects. > However, if the project is external then it might require another round of > legal reviews and approvals. We are happy to move it to eclipse. I just tried to enter a proposal but unfortunately the eclipse server crashed :-|. Will try it later again.
(In reply to Sven Efftinge from comment #7) > We are happy to move it to eclipse. I just tried to enter a proposal but > unfortunately the eclipse server crashed :-|. Will try it later again. Thanks Sven! Do you think it's worth having this as a separate project right in the beginning? The process might be easier if it's contributed an incubator first (eg., e4) and then moved to it's own project later on.
Thanks Sven! (In reply to Gunnar Wagenknecht from comment #8) > Do you think it's worth having this as a separate project right > in the beginning? The process might be easier if it's contributed an > incubator first (eg., e4) and then moved to it's own project later on. The Java implementation of this protocol can be useful to many other Java projects (the most obvious ones are other Java IDEs or development tools). So IMO, to maximize its usefulness, it makes more sense to have it as a separate project which would be an OSGi-able library, that could be consumed with Maven and p2.
(In reply to Mickael Istria from comment #9) > Thanks Sven! > > (In reply to Gunnar Wagenknecht from comment #8) > > Do you think it's worth having this as a separate project right > > in the beginning? The process might be easier if it's contributed an > > incubator first (eg., e4) and then moved to it's own project later on. > > The Java implementation of this protocol can be useful to many other Java > projects (the most obvious ones are other Java IDEs or development tools). > So IMO, to maximize its usefulness, it makes more sense to have it as a > separate project which would be an OSGi-able library, that could be consumed > with Maven and p2. I agree. I've create a proposal which I send to the emo for review. I will share the link here once it is public.
Here is the project proposal for a Java client to Language Server Protocol: https://projects.eclipse.org/proposals/lsp4j https://github.com/Microsoft/vscode-languageserver-protocol contains extensions to the generic code editor (bug 497871) that provide completion, diagnostics, Find References for C# in Eclipse IDE using the OmniSharp Language Server and the ls-api (to become lsp4j).
The LSP4J does that and is now an Eclipse.org project.
