Eclim dead?

[void-m4110c]

There has not been any action from the maintainers since 8 months. No feedback on issues or anything. This leads me to the question: Is this project dead? If so, where do we go from here? Is there a fork, that is maintained more actively? Maybe one that plans to stay "alive" for longer time? Greetz

[dansomething]

It's looking that way. https://github.com/ervandew/eclim/pull/532#issuecomment-323619909

I get it. Its a lot for one person to maintain. And with LSP gaining momentum, is Eclim still a viable approach? https://github.com/ervandew/eclim/pull/532#issuecomment-406085156

I too have been facing the dilemma of switching to jdt.ls for Java instead of using Eclim for well over a year now. While LSP seems like it could be the future, it's still immature. It lacks many features provided by Eclim. For example, there's still no good Groovy support and certainly nothing for a hybrid Java/Groovy project. You can forget about JUnit integration too among many other features.

If you do make the switch then you'd have to decide which LSP Vim client you want to use. There are several now and none of them fill all of the gaps IMO so I keep coming back to Eclim for the time being.

Are we at an impasse?

I'm curious to know how other people are dealing with this situation.

What do you other die-hard Vim/Java devs think? Where does Eclim fit in our future?

[simlei]

I think the embedded vim thing is what sets this project apart, really. Well, it would, if not for the fact that so many people seem to turn their back on eclipse. I just now took eclim up for another spin and directly ran into https://github.com/ervandew/eclim/issues/540 which seems to be an issue with the netbeans (sic!) protocol implementation between eclipse and vim -- as protected regions are a spec of that protocol according to vim docs. Well, a dated, open issue with a major showstopper, on an outdated editor protocol, developed for an IDE that is orders of magnitude less popular than eclipse even, this does not bode well.

Sad to say, but I think this project AND eclipse would have to reinvent itself to get traction again. Shame, really. I like what the author did with the project for a very long time!

PS: I am actually a sucker for well-written projects that have just happened to hit an unlucky phase. I still think this is worth investing some quality coding time into! I'll just see whether I can get my head into that bug that I hit and fix it :)

[lbrayner]

Just letting you know that, as of the 20th of November 2020 (https://github.com/ervandew/eclim/commit/99a517e836f8deb66d43266bdb7f7fb8b26ed786), the master branch builds against Eclipse 4.17 (2020-09). You can build it yourself with ant: ant installer.

[simlei]

Just letting you know that, as of the 20th of November 2020 (99a517e), the master branch builds against Eclipse 4.17 (2020-09). You can build it yourself with ant: ant installer.

That's great news! Thanks for letting me know :+1: OT: Do you have any insights into issue 600 ? If not I'll go ahead and remove this link as it serves no reference purpose...

[lbrayner]

Just letting you know that, as of the 20th of November 2020 (99a517e), the master branch builds against Eclipse 4.17 (2020-09). You can build it yourself with ant: ant installer.

That's great news! Thanks for letting me know +1 OT: Do you have any insights into #600 ? If not I'll go ahead and remove this link as it serves no reference purpose...

I never got that error ("Region is guarded") when I was using Eclim 2.8.0 with Eclipse 4.16. The errors I came upon were:

• JavaImport failing when there were multiple options;
• Generating serialVersionUID from the JavaCorrect buffer.
• JavaNew opened another window with the same buffer, although it did actually create the new file, so one had to manually open it.

All these were resolved when I built HEAD against Eclipse 4.16.

[ervandew]

As I mentioned in another issue that @dansomething linked to and summed up nicely here, I think the Language Server Protocol is the future even though functionality currently seems very fragmented. Since I'm on my own when it comes to maintaining eclim, I decided to trim out plugins that either lost upstream support (adt/android), had very limited functionality in eclim (ruby, groovy), or seemed to have little signs of usage by eclim users (c/c++, php, scala), all of which will make maintaining eclim much easier.

Eclim turned 15yrs old this past August, so I'm looking for a more modern approach to replace it eventually, but I still use eclim daily so I plan to maintain java and python support for the foreseeable future, or until the LSP implementations mature enough that switching is easier/better than keeping eclim going.

In addition to removing several plugins, I also spent time updating all of eclim's 3rd party libraries, got eclim caught up to java 11, and updated to eclipse 4.17 (2020-09). I was planning to publish a release, but now eclim is already a version behind eclipse (looks like they've moved to releasing every 3 months), so I'm hoping to get some time to update to eclipse 4.18 first.

Apologies in advance to anyone affected by the plugins I've removed, but I simply don't have the time anymore to devote to maintaining so much code :(

[ervandew]

New version for Eclipse 4.18 (2020-12) has now been released.

If you've built eclim from source you should remove your existing eclipse plugins before running the installer:

$ rm -r $YOUR_ECLIPSE_HOME/plugins/org.eclim*