[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Sidecars & Extensibility
|
I think the answer lies on the extension packaging.
I am going to start with an example from VS Code. VS Code, just like we
are planning to do, installs every extension
individually. However, the individual extensions becomes tedious for
end-users quickly and VSCode also introduced
extensions packs. Extension packs are basically a bag of extensions that
goes together well, for instance Java has two [1][2]
that I am aware of on VSCode.
Technically Che should be able to install every extension individually
on a side-car. However for practical reasons, I think
we can think of a side-car Che extension an extension pack that packages
several extensions together. We can probably make it
easier to create extension packs and even consider what Sergeii
suggested so that a side-car extension could also be configured to
enable/disable its selected set of extensions.
[1]
https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack
[2]
https://marketplace.visualstudio.com/items?itemName=pverest.java-ide-pack
Thanks,
Gorkem
On 26 Feb 2018, at 7:23, Thomas Mäder wrote:
Hi folks,
In preparation for diving into Theia development next sprint, I've
been thinking about how sidecar containers play with our vision of
Theia extensibility. I'm trying to get my understanding aligned with
everyone and feedback on my ideas, so feedback very welcome.
As an example, I'm going to use jdt.ls, but I guess the issues could
apply to other environments, as well. The particular thing about
jdt.ls is that it is extensible. So, for example, if I want basic java
support, I need jdt.ls. If I want to add debugging, I'll need a couple
of eclipse bundles developed by microsoft. To add our Che-specific
extensions, you need another set of extensions developed by Red Hat.
What I'm getting at is that we need n plugins, which we might not know
in advance. In the case of jdt.ls, they all need to run in the same
process. This means we'll can't just build a single sidecar container
and run that, we'll need to install stuff into it.
One way to do this would be to keep our installers, but target the
language-support sidecar. This would run into the problem of having no
sudo rights on Openshift, IMO.
The other way to do it would be to build a new image in order to add a
new component to the sidecar. There would have to be some plugin API
to contribute such components.
thoughts? thx.
/Thomas
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
