OSGi declarative-services does not bind services when manually installing bundles

What I am trying to achieve

Using netbeans modular system to prepare the application for us, as we implement the modules in OSGi using declarative-services via apache felix. Here is the module setup:

• Module A - Provides service A and B
• Module B - Provides service C, Reference service A and B
• Module C - Provides service D, handles the installation of module A and B
• Module D - Reference service D and B.

Module C installs modules through the following code:

BundleContext context = FrameworkUtil.getBundle(class).getBundleContext();
Bundle tcp = context.installBundle("file:Location");
tcp.start();

Where everything installs and starts without error. However the declared references are not being bound to the services.

For more specific on how everything holds together I added the code to github https://github.com/jonaslagoni/server. Remember to change the lines in file: module C, dk.sdu.ace.dp.Controller, line 27-28 to the location of module B and A.

• Module A is "TCP server OSGi Bundle"
• Module B is "Game world OSGi Bundle"
• Module C is "Dependency Controller OSGi Bundle"
• Module D is "Server Engine OSGi Bundle".

What I have tried so far

1. Based on the active issue I tried ensuring the build order of the installation so module A gets installed before module B and even the other way around just to be sure. I even tried installing the bundle after the second bundle reached the state "started".
2. Calling update on the module B after module A is started.
3. Looked up if I needed to do anything regarding registering and provide the different services manually when installing bundles, I could not find anything, or simply did not understood the answers..
4. I have tried so many silly things which probably does not make sense to try or describe here.

Extra questions

Should the declarative-services automatically bind the providers with the references when installed and started through the bundlecontext?

Is this way of structuring the application even viable, or should we pursue another way? if so which?

Your DS references are using an optional cardinality while not using greedy policy option. (reluctant policy option is the default for historical backwards compatibility reasons.)

With reluctant, the reference will not be rebound when additional/better services are later registered such as the bundle providing the service starting after the bundle consuming the service. With greedy, the reference will be rebound.