Hello,
On 10/6/20 7:07 AM, Thomas Mäder wrote:
> ...that our plugin model (contanier per plugin) is wrong:
>
> * we're investing a lot of effort into our container-per-plugin model,
> yet we can't really make it work for many vs code extensions, leading to
> weird errors and testing effort at each update
>
> * we need to run our own plugin registry with our own meta.yml, etc.,
> which is becoming a bottleneck
Some things we can do to reduce this maintenance cost:
* only one version of the plugin in the registry: we release Che often
enough that we don't need multiple versions of one plugin
* increased automation + testing (in progress)
* unify registry and sidecar image contribution process
> * we need a "dev-machine" image anyway (for example, with maven, npm,
> typescript or whatever the stack needs)
>
> * the focus seems to be on out-of-the-box experience, which could easily
> include making a specific "IDE" image per stack.
>
> * there is an effort to make the different containers invisible to the user
>
> * all other contenders in the market have a "single container for the
> IDE" model
>
> * the model only works for Theia and we seem to be starting to support
> other editors
I think there is a strong argument to be made for merging the language
sidecar and dev-machine images. Often the use cases for both of these
containers is so tightly coupled that it makes sense to combine them.
For example in Java, you'd have vscode-java (and related extensions) all
running on the java-maven dev machine container.
For non-language plugins (container tooling, for example), it still
makes sense to keep the plugins in separate containers, as there is no
overlap in the environment needed to run these tools.
Unfortunately, I think I have a use case with an overlap: for VS Code Camel K. VS Code Camel K requires VS Code Kubernetes and fits in "container tooling". But it also requires VS Code Java to provide Java completion for Camel K files (which is why the completion for Java is not still not working for Camel K files)
Eric
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
