Hi Maria,
I posted this in the Eclipse user forum but got sent here instead.
Indeed, sorry for that. LSP4E doesn't need a user forum and the -dev mailing-list is enough as there is no distinction between end-users and extenders (plugin developers) for LSP4E. So gathering everyone on the same channel is much more efficient. I've opened a bug requesting removal of the forum to avoid further confusion.
Me and my team are evaluating LSP4J and LSP4E for a plugin project which would benefit from a language server integration.
Good. I'm pretty sure you'll eventually end up adopting them as 1. the LSP stack is extremely profitable for all languages and IDEs and 2. there is by far no better alternative in the Eclipse/Java world ;)
We are already using LSP4J 0.5.0 for other projects, and we don't want to downgrade that in order to get a working
installation of LSP4E.
Is LSP4J a "singleton" bundle? If not, then multiple versions of it can cohabit in the same runtime, and properly dealing with version ranges can avoid conflicts in consumers.
If you need LSP4E to temporarily "revive" an older version to fix some version range and publish a fixed release that saves you, it's the kind of thing we can help you to do. We could start a branch from a given tag, welcome your patches on it, and when you are happy, you tell us and we release a 0.x.y+1 which includes your change and that you'll be able to consume in your product.
Is there a reason for LSP4E being dependent on these Photon specific plugin versions?
We could imagine organizing LSP4E in a way that we have separate bundles/fragments to have different feature set with different compatibility, but that increases the development effort and at the moment, I don't think the current contributors can afford it nor would have it part of their "strategy" (ie the reason why they're contributing). If you wish to invest manpower in LSP4E to support that and reorganize LSP4E in different fragments to improve compatibility, then that would probably be welcome unless it shows a major flaw. The process is as usual, to open bugs and submit patches that we'll review and hopefully merge.
Is it necessary for the code to be tied to minor and patch releases?
In semantic versioning, the minor version tells that there are new features or APIs. So LSP4E needs to mention compatibility with a minor to make sure there are the right APIs.
For the patch, we shouldn't need it. If you see an occurence where LSP4E's manifest files require such a patch version and can't see a valid reason for it, please open a bug as it could indeed be a restriction we could get rid of.
> If not, it would be nice if it could be run in Oxygen too.
Again, it's something that could probably be implemented, but since so far you're the only one who want it, you can't rely on current contributors to do it and you'll need to contribute it to LSP4E, which would be a very welcome initiative ;)
> We cannot run Photon or later because of Linux environments with
outdated versions of GTK and Cairo, so the only real solution is to
upgrade the environments. That takes some time though, since the
organisation we're working in is quite big.
Sorry to hear that. Unfortunately, this is indeed an annoying issue and I can't think of a trivial remediation here (except maybe going through containers or flatpacks as distribution, but it can be over-kill).
I know a company who has a very good professional Linux distribution with up-to-date versions of GTK and Cairo, and that tests the latest version of Eclipse IDE and its family of projects works fine on it, and that even supports it (if you have a support contract). I guess you can infer who I'm talking about looking at my signature or email address ;)
