Extract DI to separate module

[eutkin]

I've made life cycle management of scalecube services a separate subsystem: ServicesProvider.

Pro:

• The service lifecycle management logic is now concentrated in one class (ServicesProvider);
• You can replace the implementation with another IoC container (Spring/Guice/etc).
• The API is backwards compatible

ServicesProvider - interface for IoC container that performs several functions:

• stores all instances of services;
• manages the life cycle of stored services (creation -> initialization -> finalization);
• gives meta information about stored services (type and tags).

Scale Cube for DI proprietary mechanisms are collected in one class, in ServicesProvider implementation (see ScaleCubeServicesProvider).

The Spring IoC implementation is also given for the example.

[segabriel]

Please fix imports, I came across with the same problem recently and the best solution is https://github.com/google/google-java-format#intellij-android-studio-and-other-jetbrains-ides

The import ordering is not handled by this plugin, unfortunately. To fix the import order, download the IntelliJ Java Google Style file and import it into File→Settings→Editor→Code Style.

[ronenhamias]

since .services(new MyService()) is deprecated we need to update all the examples to how to use the current api correctly including the docs.

// Construct a ScaleCube node which joins the cluster hosting the Greeting Service
    Scalecube ms =
        Scalecube.builder()
            .discovery(
                endpoint ->
                    new ScalecubeServiceDiscovery(endpoint)
                        .membership(cfg -> cfg.seedMembers(seedAddress)))
            .transport(RSocketServiceTransport::new)
            .services(new BidiGreetingImpl())
            .startAwait();

[eutkin]

Create module with spring examples. And guice examples. It's not clear what we gain from all this story. It's clear what we loose, but it's not clear what we gain.

done

[eutkin]

up

[eutkin]

What other important problems remain unresolved? It's becoming more and more difficult to merge this PR with the develop branch.

[eutkin]

@ronenhamias @artem-v @segabriel

When I was writing the documentation, I found a semantic mistake. I suggest changing ServiceFactory in this way.

Why? Because otherwise it seems as if we are managing the life cycle of only those services that will be placed on the Scalecube node. In fact, ServiceFactory is needed to manage the lifecycle of all user components. But unlike DI frameworks ServiceFactory separates Scalecube services from all components.

[segabriel]

@eutkin

What other important problems remain unresolved? It's becoming more and more difficult to merge this PR with the develop branch.

I guess we need to postpone this PR for a week probably two weeks, due to we need to have a stable version of scalecube-services for this time slot. And have the ability to fast solve some shortcomings that stop us.