Rebar3 Umbrella项目：子应用监督与.app.src配置加载方案

核心方案：用included_applications加载子应用配置，手动在主监督者中启动子应用根监督者 #

具体实施步骤：

1. 确保子应用配置完整
   确认node_to_watch子应用的.app.src包含所有需要的配置项（如env字段），且已实现自身的根监督者（例如node_to_watch_sup）。

2. 调整主应用的.app.src配置
   在sup_my_apps的.app.src里，将node_to_watch加入included_applications列表，而非applications列表：

   {application, sup_my_apps,
    [{description, "Main umbrella application"},
     {vsn, "0.1.0"},
     {modules, [sup_my_apps_app, sup_my_apps_sup]},
     {registered, [sup_my_apps_sup]},
     {applications, [kernel, stdlib]},
     {included_applications, [node_to_watch]}, % 此处添加子应用
     {mod, {sup_my_apps_app, []}},
     {env, []}]}.
   

   该配置会让Erlang加载node_to_watch的.app.src配置，但不会自动启动子应用的start/2函数。

3. 在主监督者中注册子应用监督者
   修改sup_my_apps_sup:init/1函数，将node_to_watch_sup作为子进程添加到主监督树：

   init(_Args) ->
       SupFlags = #{strategy => one_for_one,
                    intensity => 5,
                    period => 10},
       ChildSpecs = [
           #{id => node_to_watch_sup,
             start => {node_to_watch_sup, start_link, []},
             restart => permanent,
             shutdown => infinity,
             type => supervisor,
             modules => [node_to_watch_sup]}
       ],
       {ok, {SupFlags, ChildSpecs}}.
   

原理说明 #

• included_applications：和applications的区别是，它仅加载目标应用的元数据与配置（包含.app.src中的env项），但不会触发子应用的启动流程（即不调用node_to_watch_app:start/2）。
• 手动启动子应用根监督者：让node_to_watch的监督树成为主应用监督树的一部分，实现sup_my_apps_sup直接管理子应用的进程生命周期。

验证方式 #

在子应用代码中调用application:get_env(node_to_watch, YourConfigKey)，确认能获取到.app.src中定义的配置值；同时执行supervisor:which_children(sup_my_apps_sup)，确认node_to_watch_sup是主监督者的子进程。

内容的提问来源于stack exchange，提问作者S0AndS0