Hi folks,
We're now adding support for Quarkus. Since the extension contributes
bundles to the jdt.ls process, it needs to run in the same container as
jdt.ls. With our current plugin system, we only have the two options of
either including Quarkus in the Java plugin or to make a separate one
including Quarkus plus the Java stuff.
The first approach makes it impossible to turn off Quarkus support and
we will always load the bundles, consuming resources. The second one
makes it impossible to mix and match extensions that contribute bundles
to jdt.ls (see
https://github.com/spring-projects/sts4/blob/master/vscode-extensions/vscode-spring-boot/package.json,
for example)
There has been discussion about this before:
https://github.com/eclipse/che/issues/12395. I think we've come to a
point where we need to solve the problem. There are two approaches I can
think of:
1. Container merging
The idea here is that we run all plugins that rely on the same image in
the same container. This would also reduce the number of containers we
have to run in general. Since there is a non-zero overhead to running a
container (even if it were just running a copy of the plugin-host
process), this might also help us run with less resources
Taking into account we are going toward real microservice architecture for IDE [1],
why we consider running several extensions in the same container as a target?
"The version 7 of Eclipse Che introduces a new model of workspaces of workspaces where the IDE is splitted into multiple micro-services running in separate containers."
2. Shared plugins folder
The second idea is that all plugins in the system live in a shared
directory that is available under the same path in all containers.
Indeed, it is probably time to solve this *technical debt of Java extension*.
I call it this way since we knew this problem (kinda same for maven, right?) but it was a
price of adopting
jdt.ls, so it is postponed debt and I'd consider it to be solved on
extension level and not changing the concept every time
(unless we are going to change it due to more generic problems).
Personally, I like 1#
Could folks like Sergei K or Mario chime in on whether you see a way
forward on this any time soon? Can you argue for 1 or 2 or do you see
other solutions?
/Thomas
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
