Add Qt extensions

[OrkunTokdemir]

Fixes: VSCODEEXT-96

• I have read the note above about PRs contributing or fixing extensions
• [] I have tried reaching out to the extension maintainers about publishing this extension to Open VSX (if not, please create an issue in the extension's repo using this template).
  I'm an official maintainer
• [] This extension has an OSI-approved OSS license (we don't accept proprietary extensions in this repository)

Description

This PR adds Qt extensions to Open VSX Registry

As a company, we signed https://www.eclipse.org/legal/eca

[OrkunTokdemir]

@gbraad @temoto @maxandersen @kalin Ping.

[peat-psuwit]

This won't work as-is. See my prior attempt (#856).

First of all, publish-extensions will not be able to figure out on its own which extension exists in which repository. So at the absolute minimum location key has to be defined.

Then, since there are multiple steps involved to build the extension in addition to standard vscode:prepublish (e.g. building qt-core, building/fetching qt-cli binary), publish-extensions will not be able to figure those steps out. So either prepublish key or custom key has to be defined.

Now, since you're the official maintainer, my understanding ¹ is that it's more preferred that the extension is published by the maintainer itself. This will make the extension appears in the OpenVSX as published by (in this case) Qt rather than by OpenVSX as if it's done by publish-extension. It will also reduce a chance that publish-extension's build process gets out-of-sync with instructions in this repo.

It seems to be easy to publish a pre-built .vsix file to OpenVSX. See https://github.com/EclipseFdn/open-vsx.org/wiki/Publishing-Extensions#publishing-with-the-ovsx-command

But if you're unable to do that for any reason and need to use publish-extension, then feel free to take my code from #856 and modify it. In particular, it would be nice to modify the build of qt-core extension so that it downloads the (corresponding version of) signed qt-cli instead of building directly here.

Footnotes

1. I'm not affiliated with Eclipse Foundation. ↩

[OrkunTokdemir]

This won't work as-is. See my prior attempt (#856).

First of all, publish-extensions will not be able to figure out on its own which extension exists in which repository. So at the absolute minimum location key has to be defined.

Then, since there are multiple steps involved to build the extension in addition to standard vscode:prepublish (e.g. building qt-core, building/fetching qt-cli binary), publish-extensions will not be able to figure those steps out. So either prepublish key or custom key has to be defined.

Now, since you're the official maintainer, my understanding 1 is that it's more preferred that the extension is published by the maintainer itself. This will make the extension appears in the OpenVSX as published by (in this case) Qt rather than by OpenVSX as if it's done by publish-extension. It will also reduce a chance that publish-extension's build process gets out-of-sync with instructions in this repo.

It seems to be easy to publish a pre-built .vsix file to OpenVSX. See https://github.com/EclipseFdn/open-vsx.org/wiki/Publishing-Extensions#publishing-with-the-ovsx-command

But if you're unable to do that for any reason and need to use publish-extension, then feel free to take my code from #856 and modify it. In particular, it would be nice to modify the build of qt-core extension so that it downloads the (corresponding version of) signed qt-cli instead of building directly here.

Footnotes

1. I'm not affiliated with Eclipse Foundation. ↩

Thank you for your detailed explanation.

I'm not sure I understand the process completely. According to this https://github.com/EclipseFdn/open-vsx.org/wiki/Auto-Publishing-Extensions, it seems okay to use Auto-Publishing as an official maintainer.

Having Auto-Publishing-Extensions build our extension will not work because we sign our executables in our extension. publish-extensions cannot do that.

it would be nice to modify the build of qt-core extension so that it downloads the (corresponding version of) signed qt-cli instead of building directly here.

That can be implemented in the future, but some server stuff should be arranged first.

It might be better to go with publishing vsix packages explicitly.