refactor plugin system to use DI instead of new operators

[akosyakov]

See for the motivation: #5760 (comment)

[JPinkney]

Hi! I'm going to see how far I can take this in this sprint :) I'm going to start with doing similar refactorings like #6148 and then go from there!

[akosyakov]

@JPinkney I though to have the following:

• have just one inversify factory which creates JSON RPC protocol and its services via child container
• turn JSON services into the contribution point:
  • JSON RPC protocol can create them instead of setting externally
  • and extenders can bind new, instead of setting externally too
• refactor services that they don't pass container anymore but use injection

It's quite a big refactoring. We should also decide how to deal with the plugin host process, since the protocol is used there. I would be fine to make it extensible with DI as well.

cc @eclipse-theia/plugin-system

[tsmaeder]

@akosyakov let's make PR's with chunks that are individually consumable rather than one big one that covers everything. The way it's easier to review and there will be less conflicts to resolve.

[JPinkney]

@akosyakov What do you mean by services? Do you mean classes that are made inside of main-context? i.e. new CommandRegistryMainImpl(...)? Because so far I've refactored those so that they don't pass the container and use injection.

turn JSON services into the contribution point:
JSON RPC protocol can create them instead of setting externally
and extenders can bind new, instead of setting externally too

I think I kind of understand what you mean but I just want to clarify: Do you mean that instead of setUpPluginAPI in main-context we should make a contribution provider that allows to contribute CommandRegistryMain, QuickOpenMain etc and then those are all created and the RPCProtocol set inside of this new method?

[akosyakov]

I think I kind of understand what you mean but I just want to clarify: Do you mean that instead of setUpPluginAPI in main-context we should make a contribution provider that allows to contribute CommandRegistryMain, QuickOpenMain etc and then those are all created and the RPCProtocol set inside of this new method?

Yes I meant this, in such way we don't pass Container around anymore and create RPC services via DI.

[tsmaeder]

Couple of thoughts:

1. A part of the plugin system (ext services) runs in the plugin host process, not the back-end
2. We can add new plugin API namespaces at compile time by contributing a ExtPluginApiProvider from a back-end extension.
3. The back-end tells the plugin host webworker (front end plugin) and plugin host (back end plugin) which modules to load to implement the ext services for that namespace.
4. The front end part (main services) is set up by calling the contribution point MainPluginApiProvider

The way to implement compile-time extensibility right now is to include extensions in a package manifes (like in theia/examples/browser, for example) and to have the theia build script generate a main script (server.js) that requires the main contribution points of those extensions. I believe it would be cleaner architecture if the plugin host process would be a separate, extensible build target the same way frontend and backend are now.

@akosyakov @benoitf opinions?

[benoitf]

I would say that we should first bring DI and then iterate to not mix problems.

[tsmaeder]

I don't think we're going to merge this one any time soon. Once we decide to revive this one, I suspect we'll have to do more than a simple rebase anyway. Closing (for now).