How difficult would integration with groovy-eclipse be?

[gatesn]

As well as Java, I'm looking for a good Groovy language server. It seems like the groovy-eclipse compiler solves a lot of the problems that arise when sources are defined in both Java and Groovy. It's also built on top of a slightly patched JDT.

Would someone be able to outline the steps involved in integrating this tool if at all possible?

[fbricon]

this could either be easy or very hard/impossible to achieve :-)

• server probably needs to be changed to support listening to non java files, this should be moderately easy
• jdt.ls extension needs to bring in groovy support plugins. But the patched jdt plugins might not be applicable to jdt.ls. Maybe @eric-milles, @martinlippert, @aclement could provide some insight.

[eric-milles]

Groovy-Eclipse is patched into the JDT. I would imagine the Language Server implementation of Groovy would be a replacement that would remove the need for patching the JDT directly.

[fbricon]

@eric-milles jdt.ls embeds the stock jdt core plugins (+ forked jdt ui classes). If you need jdt hacks for groovy support, then I assume you'd need to patch jdt.ls as well. That patching mechanism is not supported. Now if you can make groovy support work without a patched jdt, that'd be awesome :-)

[martinlippert]

groovy-eclipse is a patched JDT and as far as I know it is not possible to run the standard JDT together with the patched groovy-eclipse JDT side by side in the same installation (either Eclipse nor jdt.ls). So you would have to replace the existing JDT implementation of the jdt.ls with the groovy-eclipse version, which seems to be the wrong way in my opinion.

I think one of the benefits of the architecture of language servers is to have separate language servers for separate languages, so that you can develop them more or less independently from each other. Therefore I would not even think about adding groovy support to the existing jdt.ls, but think the other way around: how could an additional language server for groovy look like, how could such a language server for groovy be implemented, and how could you make both language servers (a groovy ls and jdt.ls) play nicely together with running side by side in the same workspace.

In such a scenario, you might even be able to implement the groovy language server using the existing groovy-eclipse implementation (if that makes sense), but that would be a pure "implementation detail" of the groovy ls.

Side note: we worked for a long time on the groovy-eclipse implementation and one of the lessons that we learned along the way was that using a patched JDT as the base architecture was the wrong decision. There are too many drawbacks. Using the language server architecture offers a much better way to implement language support and I would go that way instead of trying to integrate the old patched JDT implemention into the existing jdt.ls, dragging all the drawbacks into this again.

[gatesn]

Thanks for the responses, this has been very helpful. As you say, the intention was not to run both side-by-side in the same installation, but instead to have jdt.ls be runnable in either mode.

Given your note however, it seems like you'd recommend against using the Groovy-Eclipse compiler at all and actually just build out Groovy support against the Groovy compiler.

I think I will try running a Groovy and Java language server alongside each other. However Groovy still needs to compile Java files (albeit without the requirement of implementing the more complex LS features, such as completions) in order to compile Groovy scripts.

I wonder if separate build directories would be sufficient to allow the two to play nicely. If not, it may have to be the case that I run the Java language server with a document selector of src/{main,test}/java/**/*.java. But that would be unfortunate since then src/main/groovy/*/.java files would lack proper Java LS support.

[martinlippert]

@gatesn To be clear on that, I don't have anything against the Groovy-Eclipse compiler. It is still the best option to get Groovy support in Eclipse and could very well be used to implement a language server. The point I am trying to make is that I would vote for having separate independent language servers and use this architectural option to decouple the Groovy support from the overall Java support.

[aclement]

Just my 2c. If I wanted to do something quickly then I'd take a copy of the JDT LS, replace the JDT inside with groovy-eclipse JDT, change the package name to GROOVY-JDT LS or something like that (so it is different to JDT LS and not confused with it) and make that available for folks who want to use it. However, similarly to the "you either have JDT or you have patched JDT with groovy support" in Eclipse right now, you would have to choose whether to install the JDT language server or the Groovy-Eclipse based language server. The latter can handle all java and groovy but would be separate and be 'chasing' the evolving JDT LS. There is of course, as discussed, the alternative of implementing new language support purely based on the groovy compiler - I'm sure you can get that to work but if there are deficiencies it how it handles java, this approach won't fix that.

Some of the changes groovy-eclipse makes to JDT are suitable for integration into JDT itself right away, but some are not (in their current form) - solving that and running 'patchless' is a much bigger piece of work (IMHO).

[jechlin]

Hi there. I also would like to do this, but I don't really care about java support.

I attempted the instructions that @aclement gave... I made some progress but ended up with some errors from the language server: https://gist.github.com/jechlin/58551b7e0d15d9a6ca85bbf21e1704ea

That class is in a jar present in the plugins directory. I'm not really asking people to debug that (although great if you can). My question is, should the groovy-eclipse stuff work in headless mode? The reason I ask is that it refers to the Workbench not being created, which I understand to be the desktop UI. Should I expect that just adding the relevant plugins to the JDT LS and swapping the JDT core the groovy-patched one, would work?

I'm not really familiar with creating eclipse products or extensions, so possibly I just screwed something up. Any help appreciated.

[eric-milles]

Yes, headless mode should work. I run all the compiler and builder tests that way. I've run those particular tests with a number of the UI plug-ins missing from the workspace.

If you're getting into editor support (error in document setup participant), you'll need UI stuff.

[jechlin]

If you're getting into editor support (error in document setup participant), you'll need UI stuff.

Thanks... but the plugins containing those classes it's complaining about are present. I'll try to dig further but if you have any pointers I'd be grateful...

[dansomething]

This relates to the Groovy-Eclipse LSP discussion.

[eric-milles]

The patches to JDT Core are not that extensive. What needs to be decided is whether the patches or some form of them should be pushed into JDT Core. Or should they be applied to the JDT that the language server uses.

[gorkem]

jdt.ls uses jdt.core without changes. If the changes are on jdt.core they need to be pushed to jdt.core.