当使用Erlang的应用程序：启动或included_applications和管理员？(When

我有在另一个应用程序的目录DEPS依赖一个Erlang应用程序。

据我了解我既可以;

一）通过调用应用程序从我的应用程序，包括开始我依赖的应用程序：启动（some_other_app）的启动应用程序，并显示其运行观测范围内独立。

B）包括与我的.app文件我的依赖应用程序{included_applications，[some_other_app]}，这样应用程序被加载并没有开始，然后开始从我自己的顶层主管所包含的应用程序。这再次启动包含的应用，并显示出其在观察我自己的监督之下层次运行。

我的问题是，当我应该使用的方法呢？如果我使用选项“a”和我依赖的应用程序退出时将它重新启动，或者我应该使用方法“B”，使任何依赖我已经相应地监控？

在一个侧面说明我用钢筋打包和管理我的依赖关系。

谢谢，

安迪。

Answer 1:

在你的应用程序描述符中声明你的依赖是要走的路，所以你应该在大多数场景中使用B选项。

应用控制器将确保您所有的依赖是启动应用程序之前，且已启动（按顺序），而且也将使如果有错误的终止您的应用程序失败。此外，必要时应用控制器将关闭一切。

除此之外，如果你选择的选项A，开始应用的应用程序时：开始/ 1，默认情况下将得到临时的应用程序，所以你应该使用的应用程序：开始/ 2，通过永久原子作为第二个参数。

编辑：有你的依赖应用程序描述也有助于知名度，很容易知道你的DEPS而不扫描的源代码。

Answer 2:

你可能不应该做或a）也不是B）

从了解你一些二郎

看看章：包含的应用

建议越来越不使用包含的应用程序的原因很简单：他们严重限制了代码重用。它认为这种方式。我们花了很多时间在ppool的架构工作，使其所以任何人都可以使用它，让自己的游泳池和可以自由地做任何他们想做的事情。如果我们把它推到一个包含的应用程序，那么就可以不再被包含在该VM任何其他应用程序，如果erlcount死了，然后ppool将采取打倒它，破坏的是想任何第三方应用程序的工作使用ppool。
由于这些原因，包括应用程序通常由许多二郎程序员的工具箱中排除。我们将在后面的章节中看到，版本基本上可以帮助我们在更通用的方式做同样的（以及更多）。

在第三章发行版的话，你可以阅读有关如何几个应用程序捆绑成一个RELASE以及它们是如何开始。