[erlang-questions] Application startup order in a release

[Karolis Petrauskas]

Hello,

    My Erlang based system is composed of several applications.The
applications can be classified to Core, Plugins and Workers. All
Plugins and Workers have static dependencies on the Core only. I.e
Plugin and Worker application modules use modules from the Core, and
have the application Core listed in their *.app files. The Core
application provides several behaviours and process registries.
Plugins are providing callback modules for these behaviours and
registers corresponding processes to the registries. The Worker
applications use behaviours defined in the Core and use the registries
to lookup the needed processes. That way the Worker applications can
use Plugin processes without knowing about them in advance (behaviours
are used as interface definitions).
    I am using sys.config to wire-up all the system (telling Workers
which Plugin-provided processes to use by specifying process names).
That way I am getting runtime dependencies between the corresponding
Workers and Plugins. The corresponding Plugins should be started
before the Workers that have run-time dependencies on them.
    I am generating release (using rebar) to run my system. As I
understand, the applications are started according to their
application dependencies, as listed in the .app files. Here is my
question: how can I control application startup order in the release
without including corresponding Plugin applications into the *.app
files of the Workers? I want to keep the Worker applications as clean
as possible. Is there a way to control the startup order during
generation of the release? The only option I know is to transform the
application files after they are build (rebar compile) and before the
release is generated (rebar generate). But that sounds hacky. Maybe
there are better options or maybe my approach on managing application
dependencies is wrong?

    For example, the static dependencies are the following:
Plugin1 -> Core, Lib1
Plugin2 -> Core, Lib2, Lib3
Worker1-> Core
Worker2-> Core

    The Lib1, 2, 3 are other applications (e.g. Yaws). They are not
needed by Workers till the run-time. Even integration tests
(common-test) can be executed without them. But for the production
system the following dependencies should be added (or at least the
corresponding startup order enforced):
Worker1 -> Plugin1, Plugin2
Worker2 -> Plugin1

Karolis