tags:

views:

185

answers:

2

I've never really used the .app files for my projects. I understand those are required for loading an application through the application module.

Is there another use of such files?

+3  A: 

They're used for when building releases (with *.rel to generate boot scripts). I recommend just starting with the *.app file and the application behaviour callback though. As for starting with OTP. It is a nice sweet spot in development to do:

-module(foo).
-export([start/0]).
start() ->
    [application:start(A) || A <- [sasl, inets, x, y, etc]].

to start all the applications you depend on having running for your application with a simple

$ erl -s foo
  • If your project is to be used as a service or framework to other projects, another benefit is that those Erlang applications can in turn depend on, or include, your application. An Erlang application is the unit in which to provide services and even libraries (stdlib is a library, no "moving parts", just library modules).
  • Being an Erlang application gives you a simple way to pass configuration parameters to your application. When you pass -mnesia dir '"/some/path"' to erl, it is accessed by the mnesia application as application:get_env(mnesia, dir). If you define an application called foo, you can pass -foo key 'some-Erlang-literal' to erl. The *.app file can contain defaults in the env section, the *.rel file overrides them, and the command line overrides that.
  • The *.app file has sections where you list the modules and registered processes your application introduces. This is used when building releases to check that there are no collisions between applications.

Some additional features of Erlang applications that I don't know well:

  • Start phases. Used for applications that have complex start-up needs, such as being "partially running" for a while.
  • Distributed applications. Used to define where the application should run in a cluster.
  • Takeover. Used to release a machine from the distributed application, such as if it needs maintenance or upgrading.

Eventually you will begin to want to start your application set in a more structured way, and that is when the whole release / boot-script is going to become more understandable. Or the opposite, you will think it is overkill for you specific needs. Just start with a simple *.app and a module with the application behaviour callbacks. You wont look back.

Christian
Thanks for your contribution.I am used to packaging my applications for deployment using a Debian repository (i.e. dependencies are handled, installation/upgrade etc.). In this context, what does OTP/.app get me?
jldupont
if your .app file is setup up then the above code is superfluous. Just application:start(my_app) is all that's necessary to start all your depencies and then your app. If you have generated a boot script then you can have the above happen automatically for you when starting erlang.
Jeremy Wall
Adding to the benefits: .app files enable the boot script building to detect duplicate module or process names within the applications. Also it enables the VM to load all modules at start, so you can use embedded mode. You can also enforce the correct versions of applications, etc...
Zed
+7  A: 

The *.app along with the *.rel file is used to generate boot scripts. A boot script is used to automatically launch my application when erlang is started up. An application resource file describes what applications need to be running before my application can be launched. For instance, if I use mnesia and indicate that in the .app file for my application, when I generate a boot script and use it to start my application it will start mnesia for me when starting my own application.

While you may get automatic dependency installation/handling with other package managers the boot script is useful for managing dependencies in the startup of your application which is important in an OTP application setup.

note: applications in otp refers to a bundle of running processes and/or code. applications can depend on other applications in a number of ways. Either they require the code to be installed or they require the application to be running.

Jeremy Wall
Although I haven't encountered a situation where the order of groups of applications is important, I can appreciate its usefulness. Thanks!
jldupont