Inline Che Theia plugins and Che Editors definitions in devfile v2

[sunix]

Is your enhancement related to a problem? Please describe.

At the moment, adding a cheplugin is requiring the user to have a plugin registry and point the meta.yaml to use to another external http available resource.

Describe the solution you'd like

It would be nice if we could inline the definition of a Che Theia plugin or of a Che editor in a v2 devfile (syntax details are in this other issue):

schemaVersion: 2.1.0  
metadata:  
  name: my-example  
attributes:  
  .che/che-theia-plugins.yaml: |  
    - id: redhat/java
  .vscode/extensions.json: |  
    {  
      "recommendations": [  
        "ms-vscode.vscode-github-pullrequest"  
      ]  
    }
  .che/che-editor.yaml: |  
      id: che-incubator/che-code/insiders
components:
(...)

Once we have that, we could even imagine composing new workspace by adding custom cheplugins from the dashboard: would just choose a container image and 1+ vsx extensions from openvsx marketplace

[l0rd]

@sunix this is a good suggestion. We need to think if it's worth adding it to the v1.0 spec or we include it in the devfile 2.0 spec.

[sunix]

@l0rd I would say ASAP so both ... this is a high value enhancement and low cost as we have almost everything in place to achieve that. Would make testing new vscode extensions or sharing unsupported vscode extension or che plugin in draft mode a lot easier.
To me this is important as it will help to show the value of Che, running vscode exts in sidecar containers, to users and futur contributors.

[sunix]

devfile 2.0 devfile/api#95

[themr0c]

I agree it would be really a very nice feature. It feels awkward to have the creation of a custom plug-in registry (administrator task, out of the hands of an end-user) as a dependency to add an IDE extension (routine end-user task).

[ericwill]

I agree it would be really a very nice feature. It feels awkward to have the creation of a custom plug-in registry (administrator task, out of the hands of an end-user) as a dependency to add an IDE extension (routine end-user task).

There is another way, and that is putting a meta.yaml somewhere (GH branch, or GH gist) and pointing to that in your devfile.

https://www.eclipse.org/che/docs/che-7/administration-guide/using-a-visual-studio-code-extension-in-che/#adding-the-vs-code-extension-using-the-workspace-configuration_adding-che-plug-in-registry-vs-code-extension-to-a-workspace

[sunix]

I agree it would be really a very nice feature. It feels awkward to have the creation of a custom plug-in registry (administrator task, out of the hands of an end-user) as a dependency to add an IDE extension (routine end-user task).

There is another way, and that is putting a meta.yaml somewhere (GH branch, or GH gist) and pointing to that in your devfile.

https://www.eclipse.org/che/docs/che-7/administration-guide/using-a-visual-studio-code-extension-in-che/#adding-the-vs-code-extension-using-the-workspace-configuration_adding-che-plug-in-registry-vs-code-extension-to-a-workspace

Ok it works but hosting meta.yaml somewhere else is still painful. It is adding x2 confusion and complexity compared to this proposal.

[ericwill]

I agree, I was more suggesting that in the meantime we shouldn't encourage people to deploy an entire registry just for one extension if the hosted meta.yaml way also works. At least until we have a fix for this ticket.

[themr0c]

https://www.eclipse.org/che/docs/che-7/administration-guide/using-a-visual-studio-code-extension-in-che/#adding-the-vs-code-extension-using-the-workspace-configuration_adding-che-plug-in-registry-vs-code-extension-to-a-workspace I read:

"Change the current registry to the registry in which the VS Code extension was added."

So this is an erroneous statement.

[themr0c]

I'll try to address that in eclipse-che/che-docs#1633