In order to add an application, two files must be modified:

• The rebar.config(see Rebar dependencies)
• The rel/rebar.config (see The release config)

Exodm uses rebar's dependency support, with some in-house patches.

In the top-level rebar.config, the applications needed for the system are listed, e.g.:

{deps,
 [
    {lager, ".*", {git, "[email protected]:Feuerlabs/lager.git", "1.0.0.fl.2"}}
    ...
 ]}.

The way to read this is:

• The application lager, application version matching the regexp .* (any version), fetched from github - the latest version ("1.0.0.fl.2" - this could also be e.g. "HEAD" if one always wants the latest version).

Rebar will by default check the deps/ directory to see if the application is present. If so, it will read the .app file (e.g. lager/ebin/lager.app) and match the application version attribute against the above regexp, and abort if it doesn't match.

Note that each dependent app may have dependencies of its own. Rebar will honor transitive dependencies.

Now, the original location of lager is http://github.com/basho/lager, but we keep a fork of our own with our own tagging scheme: <OriginalTag>.fl.N, where N basically indicates our patch level above the stable version released by Basho. Note that the added commits will often be maintainer commits that we have pulled, but could also be our own patches, of course.

When in development mode, it is often convenient to have rebar find the application on your local disk. To achieve this, we use a "wrapper" script (rebar.config.script) that checks for the OS environment variable $REBAR_DEPS. If present, it patches the rebar.config, using the (single) directory given by $REBAR_DEPS in place of the default deps/ dir. This technique was initially a Feuerlabs patch, but is now part of rebar (see The rebar wiki: Dynamic Configuration)

In order to also generate and build the system using a patched deps directory, the same directory must also be included in the environment variable $ERL_LIBS. This env var is used by the Erlang code loader, and is given in standard Unix path syntax.

A special rebar plugin (exodm_rebar_plugin.erl) patches the configuration for Reltool so that it also knows where to find the applications.

A second rebar.config file exists for instrumenting Reltool.

The part of this config file that may need editing is the rel_apps option:

%% Add the apps that need to be included in the generated release
{rel_apps, "exodm",
            [kernel,stdlib,sasl,runtime_tools,compiler,
             {inets,load}, {setup,load}, {exodm_setup, load}, {sext, load},
             syntax_tools, lager, public_key, crypto, bcrypt, ssl,
             gproc, jobs, exo, yang, bert, reactor, lhttpc, ck3,
             eleveldb, sqlite3, kvdb, {gettext,load}, {yaws,load},
             {simple_bridge,load},{nitrogen_core,load},{nprocreg,load},
             exodm_rpc, exodm_http, exodm_ck3, exodm_db, exodm_web, exodm
            ]}.

The second element is the name of the release. This will correspond to the subdirectory under rel/ where the files will be generated. The list of applications defines which applications are to be loaded and/or started in the "exodm" system. The order is semi-relevant; OTP will adjust the order if needed in order to honor application dependencies, but will otherwise keep the order intact. If an application should only be loaded, it is added as e.g. {setup, load}.