Undefined dependency versions are a problem

[Bananeweizen]

The project doesn't specify which versions of Xtext, PDE etc. it depends on. That's quite bad for development and publishing, as some parts use deprecated methods, or simply lie about being able to run on Java 11 (there are transitive Java 17 dependencies meanwhile).
I'd suggest to lift the requirements to Java 21, Xtext 2.35 and release train 2024-06. That way the Xtend last() method conflict with Java 21 and several other issues can be cleaned up more easily, and several other platform breakages of the past are avoided.

Any comments?

[haubi]

Well... I'm quite hesitant in updating hard dependencies to "latest" Eclipse/Java/whatever, because I have some need here to support older versions still.
IMO, breaking with older versions requires bumping major release number, which I'd like to avoid as much as possible (depending on the effort required to retain support for old versions).
However, adding runtime-support for "latest" Eclipse/Java/whatever always is a good idea of course.

That being said: Right now, I'm absolutely fine with specifying minimum dependency versions to what comes with Java 11 and Eclipse 2022-12, even without major revbump for lcdsl, because that's what likely is required for some existing lcdsl code already.