deprecation and removal of rascal-eclipse project

[jurgenvinju]

This is to register the intent to mark "rascal-eclipse" for deprecation and eventual removal. This includes the nested project for the update site, the feature, the actual plugin, and the developers-feature that would link Rascal JUnit tests to their source locations.

• Our (new) users gravitate (by about 90%) to using VScode
• The only feature the VScode extension is missing is the interactive Rascal debugger, otherwise it is feature complete, and even more featureful than rascal-eclipse
• Basic features that we depend on, such as terminal and HTML preview, in Eclipse are not maintained well. Otherwise, Eclipse has proven to be an extremely stable platform (also given the impulse abstraction that we maintain ourselves).
• Although IDE support for DSLs based on util::IDE can not literally be used to call util::LanguageServer from the rascal-language-servers project, the concepts are exactly the same and only some minor rewiring is requested.
• vis::Figure was not used by many students anymore, but still we have to bring the documentation of vis/* and salix-* up to the level of the Figure library
• by removing such code we improve the general sustainability of what is left
• we have to wait at least a year from this day (Feb 2nd, 2023) to give users time to migrate to VScode
• we can only drop Eclipse when we have the debugging feature in VScode, as it is essential for the bootstrapping of the compiler.

Please sign here for the consent of the idea:

• [x] @jurgenvinju
• [ ] @PaulKlint
• [x] @DavyLandman
• [ ] @tvdstorm

In the meantime we will make only small bugfix releases of rascal-eclipse, to help straggling users while they prepare to migrate. I will add a documentation issue about documenting the migration from rascal-eclipse DSL implementations to VScode DSL implementations

[DavyLandman]

We should start printing a deprecation warning in the repl of eclipse? (with some link to a blogpost describing it)

[jurgenvinju]

TODO for this to work out fine:

• [ ] email teachers about the deprecation and the migration deadline
• [x] update README files of respective projects to include mention of the deprecation
• [ ] write deprecation blogpost
• [ ] include deprecation notice in release notes for bug fix releases
• [ ] port Rascal debugger to VScode
• [ ] print deprecation warning in terminal
• [ ] write migration guide from util::IDE to util::LanguageServer
• [ ] document salix-core and salix-contrib as well as the vis::Figure library

[jurgenvinju]

There is an opportunity to factor vis::Figure into a separate maintainable project, where SWT is used or SVG output is created based on an SWT graphics environment that can output SVG. However, there are also ports of vis::Figure out there already that generate JS/HTML/SVG, and a salix enabled port as well. So before we delete rascal-eclipse, we also have to think about the future of vis::Figure.