migrate vscode-extensions.json to a che-theia-plugins file

[benoitf]

Is your task related to a problem? Please describe.

Today, vscode-extensions.json file defines a list of vsix to analyze to detect new updates.
But we've some che plugins referencing multiple vsix and some vsix are not available as a single che-plugin.

and then we still have the v3/plugins folder so contributors need to update different files with the same information

Describe the solution you'd like

Have a single file describing all plug-ins:

• it should include the minimal information if a chePlugin match a single vsix
• if a che plugin includes several vsix, then we can specify the information about vsix alongside.

example to list several vsix:

---
chePlugins:
- id: redhat/java
  ...
  sidecar:
   image: quay.io/eclipse/che-sidecar-java:11-7bd8c8c
   source:
     repository: https://github.com/che-dockerfiles/che-sidecar-java
  extensions:
  - repository: https://github.com/redhat-developer/vscode-java
    revision: v0.69.0
  - repository: https://github.com/redhat-developer/vscode-java-debug
    revision: v0.1.2.3

example if we want to have a vsix directly exposed as a chePlugin with all default options:

chePlugins:
- repository: https://github.com/microsoft/vscode-pull-request-github
  revision: 0.20.0

Describe alternatives you've considered

could be json or yaml but maybe as we may include fragments of devfile.yaml should be done in yaml.

Additional context

Idea is to be able to completely remove v3/plugins folder and have index.json and meta.yaml files automatically generated
This file should be used to generate devfile 2.0 yaml files as well

one source, multiple outputs

[l0rd]

We had talked about having 2 files at some point: one for single vsx files and one for bundles. At least, as an external contributor, it would make things simpler and consistent with vscode. Is that still relevant?

And sidecar.source.repository is actually the URL to the Dockerfile right? Could we change the name to sidecar.Dockerfile then?

[benoitf]

the 2 files will come in another iteration
That said it may not be easier as you'll need to write a extension pack and for that you'll need a repository as well

For the sidecar as Eric already moved side-cars to same repo it will be more sidecar/directory with the relative link to the sidecar folder and option to have sidecar/image where I can provide directly my image

[l0rd]

@benoitf makes sense 👍

[ericwill]

@benoitf how do we want to handle extensions that have invalid repos? For example, some repositories upload a vsix as a GH release asset, but the repository itself has no package.json or other source code for building the extension.

[benoitf]

do you have examples ?
But is it related to this issue or it's for 'build vsix from sources' issue ?

[ericwill]

do you have examples ?
But is it related to this issue or it's for 'build vsix from sources' issue ?

For example the broadcommfd/debugger-for-mainframe plugin has this repository, but there is no extension source code there.

It's an issue because generating the meta.yaml automatically requires scraping the extension's package.json. Not directly related to this issue but it seems we should handle it now instead of later.

[ericwill]

Same question for built-in extensions, for example we are shipping the TypeScript extension as a separate plugin in Che but in VS Code it's a built-in. I suppose we could host such cases on che-incubator: https://github.com/che-incubator/ms-code.typescript

[benoitf]

For broadcom maybe we can require source code to be available somewhere optionally ( like zip file to source code, release, etc) or we drop plug-in if source code is not provided.

License is Apache License 2 so code should be available somewhere

For typescript we can reference https://github.com/microsoft/vscode/tree/master/extensions/typescript-language-features

[ericwill]

do you have examples ?
But is it related to this issue or it's for 'build vsix from sources' issue ?

For example the broadcommfd/debugger-for-mainframe plugin has this repository, but there is no extension source code there.

It's an issue because generating the meta.yaml automatically requires scraping the extension's package.json. Not directly related to this issue but it seems we should handle it now instead of later.

cc @filipkroupa can you shed some light on this? Maybe you could point us to the source code for the broadcommfd/debugger-for-mainframe plugin?

[filipkroupa]

@ericwill I cannot share source code of broadcommfd/debugger-for-mainframe, this project is not open-source.