Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Sidecars & Extensibility
And hopefully sudo isn't required for that...

On Feb 26, 2018 7:55 PM, "Sergii Kabashniuk" <skabashn@xxxxxxxxxx> wrote:


On Mon, Feb 26, 2018 at 7:53 PM, Thomas Mäder <tmader@xxxxxxxxxx> wrote:

Ah, not that is done via the vscode registry.

Can we go in the same way like we are going with Theia image?
Like, provide with environment variable with a list of plugins and
entry point of this image knows what to do with it to run JDT.LS with this plugins downloaded from vscode registry?
 


On 02/26/2018 06:31 PM, Sergii Kabashniuk wrote:


On Mon, Feb 26, 2018 at 7:25 PM, Thomas Mäder <tmader@xxxxxxxxxx> wrote:

@ashumilova ? ;-)

No I think this is question to you.
Do you know if there is plugin registry for jdt.ls plugins?
Like npm registry for Theia plugins. 


On 02/26/2018 06:18 PM, Sergii Kabashniuk wrote:
@Thomas Is there any plugin registry as npm for Theia? 

On Mon, Feb 26, 2018 at 7:11 PM, Thomas Mäder <tmader@xxxxxxxxxx> wrote:
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

_______________________________________________
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


_______________________________________________
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


_______________________________________________
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

Back to the top