groovy-eclipse
groovy-eclipse copied to clipboard
groovy
Move Groovy tooling to the Language Server Protocol allowing consumption in Eclipse and Visual Studio Code
We are currently building language server protocol based support for Dart in the https://github.com/vogellacompany/eclipse-dart project.
Do you have plans to move also to a language server protocol based approach? The big advantage is that the server implementation can be in Groovy and that the editor support in Eclipse requires only ~50 lines of code.
Also see: https://github.com/palantir/language-servers/tree/develop/groovy-language-server
"Do you have plans to move also to a language server protocol based approach?"
Ah, sorry I fought your were asking me something.
In the Eclipse project we usually tag user bugs with a similar flag if we are waiting for the user to answer.
Thanks, Lars
I have been laying back, watching the LS/LSP mature a bit. I see that Spring Tools has moved to using this approach.
Based on what I have seen and understood so far, I can see 3 options for Groovy:
- implement a standalone language server
- implement a proxy server for the Java LS
- patch the JDT within the Java LS
My concern is the support for joint compilation with Java. That is, Java and Groovy sources that are co-located and may have bi-directional dependencies. This is what the current tooling provides and the main reason why JDT Core is patched.
I am leaning towards providing a patch to the Java Language Server since it is based heavily on JDT. However, I don't want to have to support another patch. I was asked about this some time back, but have not heard if the effort to use the Groovy JDT patch actually was tried in the Java LS.
Maybe it is worth to ask the Groovy devs what they think about the LSP and how they would implement it for Groovy if they were to?
- What sorts of features would you need to give up if you moved groovy-eclipse to LSP?
- What sorts of new features would you get (almost) for free?
- How much code would you be able to deprecate?
If the answers are: not much, lots, and lots, then I'd say that it's a great idea. If the answers are different, though, then more thought needs to go into any potential switch in order to enumerate the advantages.
From a Greclipse user point of view, having a Groovy LSP would be great because if Eric for any reason won't be able to work on Greclipse any more, the risk for Greclipse to be abandoned again (and, with it, proper Groovy support in Eclipse) is very high, like it happened in the past after Pivotal decided to cease supporting Greclipse development. If I understand it well, with a Groovy LSP, instead, the chance that other devs will work on it (given the fact that it's IDE agnostic) is probably higher and the Eclipse-specific part to get proper Groovy support would be extremely reduced. Correct me if I'm wrong.
Also, #396 could probably finally become reality! :-)
If Groovy would provide a language server support in Eclipse is trivial. We recently integrate a Dart language server into Eclipse within 30 min.
Thoughts:
- implement a standalone language server pro: simpler to implement con: lesser functionality -- no joint compilation pro: could be its own project disconnected from groovy-eclipse with community support
- implement a proxy server for the Java LS pro/con: possibly simple extension to Java LSP, maybe not con: relies/depends on Java LSP pro: could provide (one-way) joint compilation support
- patch the JDT within the Java LS pro: provide bi-directional joint compilation support con: definitely depends on Java JDT and LSP
JDT-ls and JDT are very open these days, its not like in "the bad old" Eclipse days in which patches were not reviewed or well received.
So if you have a patch for JDT or JDT-ls please create a Gerrit for it and let me know. I can ask one of the new committers to review it. JDT-LS is mainly Redhat these days so we should be fine here.
If you need help with Gerrit let me know, setup usually takes 5-10 minutes and I'm happy to help you.
Thanks for that. Would you have time to review the GDT architecture and say if the approach would be acceptable for general JVM language support? https://spring.io/blog/2009/07/30/a-groovier-eclipse-experience
I've had questions from Kotlin developers about using this approach for Kotlin support. I don't want to get into a protracted process of trying to get the JDT patches merged back to JDT Core if the general approach was not going to work for any other languages.
Hi Eric, sorry trying to understand the Groovy architecture this is beyond my available time capacity. If you push a code change, that is way easier to understand for our team, assuming that the change is not huge.
Best regards, Lars
On Thu, Apr 11, 2019 at 4:37 PM Eric Milles [email protected] wrote:
Thanks for that. Would you have time to review the GDT architecture and say if the approach would be acceptable for general JVM language support? https://github.com/groovy/groovy-eclipse/wiki/Groovy-Eclipse-Architecture
I've had questions from Kotlin developers about using this approach for Kotlin support. I don't want to get into a protracted process of trying to get the JDT patches merged back to JDT Core if the general approach was not going to work for any other languages.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/groovy/groovy-eclipse/issues/811#issuecomment-482141538, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIihrTQKZR94VgY9qZar3nYi24-9Zcmks5vf0jAgaJpZM4a9kBf .
-- Eclipse Platform project co-lead CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com
I think the point here is exactly that the change is huge (or at least "important")! :-) Probably Eric meant to say he firstly needs an opinion on whether the approach is correct/encouraged and, if so, a discussion about the changes to apply to JDT may then start...
Myself, being completely ignorant on this, I've always wondered why JDT does not provide some extension mechanism to make this work and Greclipse always had to provide a "patch" (which sounds to me like a short-term workaround to the problem).
@vogella The high-level design is this:
- Provide content type extensions to the Java Source File. That is, Groovy sources are seen as Java sources, much like Java sources are also seen as text files. Because of this Groovy sources are seen by the Java Builder.
- Patch Java Builder (aka JDT) to check the content type of each compilation unit. When an "interesting type" is found, call out to a LanguageSupport extension. This is typically done for parsing, but also comes into play for things like default imports.
- LanguageSupport extension is responsible for calling out to language-specific tooling and then transforming results into JDT data types. For example the parser translates Groovy AST into JDT's AST (see GroovyCompilationUnitDeclaration).
- Similar hooks exist so that language-specific tooling participates in Java search, refactoring, etc.
Does it seem reasonable that Groovy, Kotlin, Scala, etc. could be compiled using extensions to the Java Builder? This is how joint compilation is achieved and bi-directional dependencies are supported. If this design seems useful, then I could start the process of incorporating it into JDT Core proper.
Sounds good to me but I'm not a JDT committer so my opinion does not really matter here. Maybe you can open a bug report and make this proposal and see what the JDT developers think.
There seems to be a groovy LSP implementation that already supports quite some features: https://github.com/prominic/groovy-language-server
- patch the JDT within the Java LS
My concern is the support for joint compilation with Java. That is, Java and Groovy sources that are co-located and may have bi-directional dependencies. This is what the current tooling provides and the main reason why JDT Core is patched.
I am leaning towards providing a patch to the Java Language Server since it is based heavily on JDT. However, I don't want to have to support another patch. I was asked about this some time back, but have not heard if the effort to use the Groovy JDT patch actually was tried in the Java LS.
My hunch is that these patches are breaking the ability to use the Kotlin plugin in a Java/Groovy/Kotlin projects which is becoming quite common at least in my company. I haven't been able to upgrade since the 2020-06 train because of the conflicts. Anything recent throws ASM exceptions in the editors and trying to run Groovy tests.
@nniesen If you have identified an issue with Groovy tooling, please feel free to submit a new issue ticket with details.
There were a couple historical efforts to get the patches merged into JDT Core proper. There was much resistance to this and sticking with a bundle patch means much quicker issue resolution. I think the Kotlin tooling takes the same approach as Scala tooling in that it employs aspects to inject its patches at runtime. Wouldn't be surprising if this introduced issues to Java or Groovy support.
Related: https://github.com/eclipse/eclipse.jdt.ls/issues/491.
While I had some success with https://github.com/prominic/groovy-language-server (now https://github.com/GroovyLanguageServer/groovy-language-server) but it's still quite painful especially when working on projects involving multiple languages. We're trying to implement the main logic in Java but use Groovy for testing to take advantage of the power of Spock. With https://github.com/dansomething/coc-groovy, I still need to do quite some manual configuration and since I've basically got 2 language server running side-by-side, querying definitions/references/etc seems impossible. So it'll be awesome if a language server can actually handle these JVM languages together.
Sorry my comment didn't add much value to the conversation.
Supporting LSP seems like a bigger issue for groovy then just supporting eclipse. Getting decent LSP support in opens the door to vscode and eclipse che and other more "modern" IDES. Keeping a present in the current tooling is a big part of keeping the language present as well.
