[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Sidecars & Extensibility
|
Yes, but...
Thing is, we're once again at the point where we're the choke-point of
getting stuff into the IDE. You'll have the bundle by us, you'll have
the bundle by IBM (perhaps), but if you want to write a plugin for
Checkstyle, for example, you can't, if you can't get into our
distribution. It as if you had no possibility to install additional
programs after you've installed Linux.
That is not an ecosystem, it's a product.
/Thomas
On 02/26/2018 05:41 PM, Gorkem Ercan wrote:
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
_______________________________________________
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
