Che plugin that extends a existing plugin

[sunix]

Is your enhancement related to a problem? Please describe.

In many situation, a devfile should have the ability to use an existing plugin but with additional vscode extensions.
For instance:

• The quarkus plugin could extend the Java11 plugin (adding vscode ext) or the Java15 plugin (if one day it exists)
• The lombok plugin could extend any of the Java based, could be quarkus or Java11 or java8
• the tekton plugin could extend the openshift plugin or the kubernetes plugin

Describe the solution you'd like

So let's say we have cool2k/vscode-lombok/latest that is defined with in the plugin registry with an attribute basePlugin

apiVersion: v2
publisher: cool2k
name: vscode-lombok
version: 1.0.2
type: VS Code extension
repository: 'https://github.com/GabrielBB/vscode-lombok.git'
spec:
  basePlugin: redhat/java/latest
  extensions:
    - 'https://open-vsx.org/api/cool2k/vscode-lombok/1.0.2/file/cool2k.vscode-lombok-1.0.2.vsix'

in The devfile we would have:

  - type: chePlugin
    id: cool2k/vscode-lombok/latest
    extends: 
      - redhat/java11/latest
      - redhat/quarkus/latest

or

  - type: chePlugin
    id: redhat/quarkus/latest
    extends: 
      - redhat/java11/latest

Describe alternatives you've considered

There are merge plugin capabilities but these are very limited as it would merge the plugins with the same base image. For the lombok example, it would be hard to use as we would need to define lombok plugin per version of Java

Additional context

N/A

[ericwill]

It's a nice idea, but comes with some significant corner cases that need to be addressed:

• what happens if the extending plugin needs it's own dependencies/sidecar container?
• what happens if the extending plugin has version incompatibilities with the plugins in the "base" plugin?
• what do we gain by introducing an inheritance system into the plugin registry?

[tsmaeder]

what do we gain by introducing an inheritance system into the plugin registry?

we get from an mn problem (javaquarkus*lombok, etc.) to an m+n problem. In particular, the quarkus plugin could be formulated as an extension to the Java plugin which could be freely combined with the lombok plugin, for example.

Since we have dependencies between VS Code extensions already (we just ignore them at the moment, if I recall correctly), that problem needs solving anyway and is not an argument against the proposal.

I agree that the sidecar problem needs a solution. I've proposed a long time ago that we merge all extensions requiring the same sidecar image in the same container. We already merge plugins that do now specify a container into the Theia IDE container. Why not extend that to all images? It would also save runtime resources.
We could then interpret the "extends" clause to mean "needs to run in the same container". If both plugins require the same sidecar, we can merge the containers and all is well. If we can't it's a configuration error. Additionally, if a che plugin does not specify a container, but has an "extends" clause, it would be run in whatever container the extended plugin runs in.

[benoitf]

just a FYI, but merging sidecar containers using the same image into a single one is possible by enabling a flag in devfile.yaml

[tsmaeder]

@benoitf do we have documentation on this? Asking because until this moment, I was not aware that such a feature existed.

[benoitf]

https://www.eclipse.org/che/docs/che-7/end-user-guide/making-a-workspace-portable-using-a-devfile/#_attribute_mergeplugins

[benoitf]

and related issue: #15373

[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.