Discussion: Contributing to eclipse-language-service from MelnormeEclipse
Closed this issue · 5 comments
@mickaelistria you've made some calls for contributions so I'd like to leave my thoughts on that, from my part.
My initial impression of eclipse-language-service is that, of that the things that it does (or aims to do) that are of interest to me, there is a lot of overlap in scope with https://github.com/bruno-medeiros/MelnormeEclipse. But in that regard MelnormeEclipse is ahead in terms of functionality already implemented. (mostly UI boilerplate/widgets and a miscellanea of helpers and Eclipse integration code for basic functionality like hover, find-def, code completion, etc.)
This means that most contributions that I could make to eclipse-language-service would be taking code from MelnormeEclipse and applying it to ELS (see for example #14 (comment) ). The thing is, I would only be interested in doing that if the contributed code can still make full use of the utility classes and common components that MelnormeEclipse uses.
MelnormeEclipse is heavily refactored into common utlility code, and in many cases eschews traditional Eclipse idioms. For example, it doesn't normally use CoreException, but instead https://github.com/bruno-medeiros/MelnormeEclipse/blob/master/melnorme_util/src/melnorme/utilbox/core/CommonException.java , which is similar to CoreException except it's in a bundle that does not depend on OSGi (or anything else), plus it has a few minor API constraints (like, a message is required).
Another example is the concurrency utils (https://github.com/bruno-medeiros/MelnormeEclipse/tree/master/melnorme_util/src/melnorme/utilbox/concurrency) which do severaly things, but the main one is that they wrap the standard Java Future API with one that is more type-safe (or specific) with regards to exceptions. I'd want to use that if working against LSP4J code for example, which is heavily based on futures.
There are many other examples of utility code like that.
If i was to contribute MelnormeEclipse code to ELS without being able to use that common code, in most cases it would have to be modified heavily, which not only would mean more work, but IMO it would make the code worse. So generally speaking it's not something I would be interested in doing. (unless someone pays me 😆, that's a different story...)
So the question here is, how willing would you be to accept such common code in ELS. At the very mimimum I'd want the melnorme_util bundle, but even just that might not be enough as there is also a lot of common code in the other 3 bundles (tooling, ide.core, ide.ui). But I imagine quite a few things there (like this core Melnorme design principle) would look very alien to Eclipse developers, and even Java developers in general.
Note: It's not something l'm looking for an answer right now, as in any case I'm not doing any Eclipse LSP related work at the moment: I'm busy working on the Rust side of things. But I wanted to explain what is for me, eventually, an obstacle to contributing. Especially as there isn't much at the moment that ELS has to offer to MelnormeEclipse - the LSP4J-Eclipse integration is the main thing - but that seems fairly simple once one already has LSP4J itself, and UI boilerplate. Things would get more interesting if/once ELS had support for language functionality that MelnormeEclipse currently doesn't, like #11 or #56 , or find-references, etc.
Another question/issue for me is, how commited are you (and/or your employer) to developing ELS to maturity and beyond? Are there plans to mature ELS, sustain it and keep it up to date? Or is it gonna wither like DLTK without bearing much fruition? This is likely a question that you can't give a concrete answer to, I understand, but it's another concern of mine. (MelnormeEclipse was a user of DLTK in its early stages, but it was disappointing to see that DLTK stagnated and didn't go anywhere.)
MelnormeEclipse is heavily refactored into common utlility code, and in many cases eschews traditional Eclipse idioms. For example, it doesn't normally use CoreException, but instead https://github.com/bruno-medeiros/MelnormeEclipse/blob/master/melnorme_util/src/melnorme/utilbox/core/CommonException.java , which is similar to CoreException except it's in a bundle that does not depend on OSGi (or anything else), plus it has a few minor API constraints (like, a message is required).
PS: Another example is, MelnormeEclipse doesn't use org.eclipse.core.runtime.OperationCanceledException but its own melnorme.utilbox.concurrency.OperationCancellation which also is in a bundle that does not depend on OSGi - but the main difference is that OperationCancellation is a checked exception, not an unchecked one like OperationCanceledException. Again, this is keeping in line with this principle: https://github.com/bruno-medeiros/MelnormeEclipse/wiki/Extensive-Compile-Time-Checking.
I'd rather avoiding adding dependencies to Melnorme (or other) non-Eclipse.org project. The reason is that as this code is meant to get to Eclipse.org at some point of time, it has to remain simple to review in term of IP. Adding a dependency to or shipping parts of established projects really make the move to Eclipse.org more complex.
Moreover, the example you give about some utility classes to not depend on OSGi seem useless in the context of the language server integration. This integration is about providing results of LSP requests into Eclipse editors, and Eclipse editors are inside OSGi context and that will likely not change soon (if ever). I don't get what would be the value to add dependencies on such features in a project that don't need them. It's introducing complexity and increasing maintenance cost.
The scope of this project is solely integration with LSP4J. This project has no mean to implement language functionality at all. That's another layer or silo. From eclipse-language-server or LSP4E or ecLSP (name still to be thought of), the language is a blackbox inside the language server and we don't want to open that blackbox nor to care about what's in it. I think that's where this project and Melnorme diverge in term of goals.
Another question/issue for me is, how commited are you (and/or your employer) to developing ELS to maturity and beyond? Are there plans to mature ELS, sustain it and keep it up to date? Or is it gonna wither like DLTK without bearing much fruition? This is likely a question that you can't give a concrete answer to, I understand, but it's another concern of mine. (MelnormeEclipse was a user of DLTK in its early stages, but it was disappointing to see that DLTK stagnated and didn't go anywhere.)
There is nothing official. Let's just say that Red Hat currently would like language servers for everything, and in every dev tool. The rationale is obviously about factorization of effort and reducing cost of supporting multiple tools. The Eclipse integration with LSP4J will move to Eclipse.org as soon as the 1st build of LSP4J@Eclipse.org has happened, and I'll hopefully keep working on it as long as it can offer value.
The Eclipse project proposal for the move to Eclipse.org should be open for review and support on the week after EclipseCon Europe.
As a concrete personal plan (which means it's not something that I'm requested to do but more a user story that guides me in this development), I'd like to see this project, together with Omnisharp -or C# SDK if the LSP is implemented in it in a future version-, as a way to implement an "Eclipse IDE for C# developers" package, maybe for Oxygen. And as I'm a former OCaml enthusiast, maybe an "Eclipse IDE for OCaml developers" too ;)
I don't think there is much more to say nor resolve here. Contributions are welcome, as long as they add value for the project and don't introduce complexity that's not need for this use-case.
The scope of this project is solely integration with LSP4J. This project has no mean to implement language functionality at all. That's another layer or silo. From eclipse-language-server or LSP4E or ecLSP (name still to be thought of), the language is a blackbox inside the language server and we don't want to open that blackbox nor to care about what's in it. I think that's where this project and Melnorme diverge in term of goals.
When I said language functionality, I meant functionality like code completion, hover, find symbols, etc, all, of that. I didn't mean language-specific functionality. Melnorme also doesn't have language-specific functionality, nor it is it a framework for building a language engine/server (like say IntelliJ's OpenAPI). Most of the utility and boilerplate is about interacting with externals tools that provide engine functionality, not creating your own engine.
The main difference is that Melnorme is a library, and meant to be used by a concrete, language-specific IDE, whereas eclipse-language-server is more amenable to be used by a generic component like the generic editor. (but also a language specific IDE of course)
Moreover, the example you give about some utility classes to not depend on OSGi seem useless in the context of the language server integration. This integration is about providing results of LSP requests into Eclipse editors, and Eclipse editors are inside OSGi context and that will likely not change soon (if ever). I don't get what would be the value to add dependencies on such features in a project that don't need them. It's introducing complexity and increasing maintenance cost.
The point of refactoring it outside of OSGi, is that it could be used in projects other than Eclipse. Thus attracting more users, contributors, etc, which would improve the quality of those components.
In the OSS communities of other languages: Go, Node.JS, Rust, Ruby and others, there is this culture that if you have some component, however small, of your OSS project could be useful to others, you package it separately and make it available for others in the package repository system of that language.
But, I agree it is a bit of pipe dream trying to do that here - there is no culture of doing things this way not just in Eclipse, but in the Java community in general. In part because Java is older, but mainly because it has no official package management and distribution system. It's fragmented in OSGi, Maven and maybe even other systems (Gradle?). I guess in the Eclipse IDE community there is also the case that most contributors are backed by a company that has some commercial product built on top of the IDE, which also makes it less likely for them to value abstracting a component so that it can be used in other Java IDEs. Anyways, it is what it is. I agree it would not work well for one to try to go against that.
I think the LSP4J (formerly ls-api) project covers the non-OSGi parts and is free to be reused in any Java world. I hope this one will attract the non-OSGi contributors. I do not see how an Eclipse-specific integration can provide anything that doesn't require Eclipse or OSGi. If it does, we should consider moving those very non-OSGi non-Eclipse parts to LSP4J directly.
In any case, if you identify pieces of code that can provide value of other Java applications without depending on Eclipse nor OSGi, feel free to suggest improvements, but it will require actual usage scenario to highlight the value/cost ratio.