When to use erlang application:start or included_a

问题:

I have an Erlang application which has a dependency in its deps directory on another application.

From what I understand I can either;

a) start my dependent application from my including application by calling application:start(some_other_app) which starts the application and shows it running standalone within Observer.

b) include my dependent application in my .app file with {included_applications, [some_other_app]} so that the application is loaded and not started and then start the included application from my own top level supervisor. This again starts the included application and shows its running below my own supervision hierarchy in Observer.

My question is when should I use either approach? If I use option “a” and my dependent application exits will it be restarted or should I be using approach “b” so that any dependencies I have are monitored accordingly?

On a side note I use Rebar to package and manage my dependencies.

Thanks,

Andy.

回答1:

Having your dependencies declared in your application descriptor is the way to go, so you should use option B in most of the scenarios.

The application controller will ensure that all your dependencies are present and started (in order) before starting your application and will also make your app fail if those terminate with errors. Also, the application controller will shutdown everything when needed.

Other than that, if you choose option A, when starting an application with application:start/1, you will get a temporary application by default, so you should use application:start/2, passing the permanent atom as the second argument.

EDIT: Having your dependencies in the application descriptor also helps visibility, it's easy to know your deps without scanning the source code.

回答2:

You probably shouldn't do either a) nor b)

From Learn You Some Erlang

Look at the chapter: Included Applications

It is more and more recommended not to use included applications for a simple reason: they seriously limit code reuse. Think of it this way. We've spent a lot of time working on ppool's architecture to make it so anybody can use it, get their own pool and be free to do whatever they want with it. If we were to push it into an included application, then it can no longer be included in any other application on this VM, and if erlcount dies, then ppool will be taken down with it, ruining the work of any third party application that wanted to use ppool.

For these reasons, included applications are usually excluded from many Erlang programmers' toolbox. As we will see in the following chapter, releases can basically help us do the same (and much more) in a more generic manner.

In the chapter Release is the Word you can read about how several applications are bundled into a relase and how they are started.

回答3:

I had a similar question, How do you include dependencies in an erlang project, and then how do you release them?

I had some help from various friends, and the erlang mailing list...and after re-reading some docs and more trial and error... I figured some stuff out. It's long, so check out the gist:

https://gist.github.com/3728780

-Todd