Move che tasks related logic to extension

[RomanNikitenko]

Is your task related to a problem? Please describe.

At the moment che tasks related logic is placed in task plugin.
I would like to discuss withing this issue if we still should keep it as plugin or we should consider moving this logic to extension.

Theia has the corresponding plugin API to manage tasks related system. But one of the problems is:

• che tasks are remote tasks, they are run in separate containers
• thus we are using remote terminals to display output for them
• AFAIK one of our goals is ability to run vs code tasks in separate containers

Also from time to time we have to provide che specific API or move some logic on plugin-ext side.
I believe it would be more simple and more reliable to manage che tasks related logic from extension side.

Describe the solution you'd like

Move che tasks related logic from plugin to extension

[RomanNikitenko]

@benoitf @l0rd @scela @azatsarynnyy @ericwill
please let me know your opinion

[ericwill]

Are there any downsides to moving this to the extension side? Running tasks in separate containers is definitely something we are interested in supporting, so the work is valuable from that POV alone.

[tsmaeder]

AFAIK one of our goals is ability to run vs code tasks in separate containers

That would be very cool, indeed

[ghost]

I don't have an opinion. What I do think though is that Roman knows this area well so if he says so there must be good reasons.

…

On Tue, May 12, 2020 at 10:45 AM RomanNikitenko ***@***.***> wrote: @benoitf <https://github.com/benoitf> @l0rd <https://github.com/l0rd> @scela <https://github.com/scela> @azatsarynnyy <https://github.com/azatsarynnyy> @ericwill <https://github.com/ericwill> please let me know your opinion — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16893 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKON55HATBYKS6OLXJZBTRRED77ANCNFSM4M6T2QPQ> .

-- Sopot Cela Software Engineering Manager <https://red.ht/sig>

[azatsarynnyy]

Are there any downsides to moving this to the extension side?

That's a good question @ericwill
And the short answer is - there are absolutely no downsides. On the contrary - it provides a lot of benefits in our case.

Note, I'm not comparing Theia Plug-ins and Extensions in general but I'm talking specifically in the context of the functionality of supporting Che Commands in Che Theia.

Now, I'd like to give a more detailed answer for a better understanding of the reasons and motivations behind that.
Currently, Che Task Plugin doesn't benefit from any of Theia Plug-ins advantages. Let's look at them:

• we don't benefit from the code isolation as we trust the code we own and maintain, unlike the 3'rd party plugins;
• one doesn't need to (un)load the code at runtime enabling/disabling the Plug-in for different Workspaces. As Task Plugin actually is an integral part of Che Theia;
• reduced compilation time - there're very rare cases when it's not needed to recompile the whole Che Theia as the related code is not on the Plug-in side only but on the main Che Theia application as well (aka plugin-ext);
• self-contained artifact - Che Task Plugin doesn't have external dependencies so it doesn't need to be run in a separate sidecar;
• simple Plug-in API - Task Plugin is very complex and only a part of the functionality is implemented with Theia Plug-in API.
  VS Code compatible Theia Task Plug-in API doesn't provide all the required capabilities, e. g. running the commands remotely or adding custom macros. That's why we also have Che Theia Plug-in API which provides all the accompanying functionality.
  And another part is in Extension, plugin-ext;
• no InversifyJS - we do need DI framework.

In addition to the mentioned above, ^^ what we'd gain more, having Che Commands support in Che Theia through Theia Extension?

• reduce the amount of data (de)serializations and JSON-RPC communications overhead. That's critical on such infrastructures as Hosted Che. BTW that's one of the reasons for the general slowness of Che Tasks there, e.g. fetching, resolving, running.
• lower maintenance cost since we'll get rid of a lot of extra burdens to maintain the layer of Che specific Plugin APIs that exposes Theia's components, e.g. Che Tasks Runner API, Che Macros Resolver API;
• move forward much faster and easier with the new features or while investigating the bugs. As we'll be able to just tweak the required Theia functionality by overriding/rebinding the interesting components.

[ericwill]

Thanks for the very detailed answer! 👍 from me

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.