Provided by: erlang-manpages_14.b.4-dfsg-1ubuntu1_all bug


       app - Application resource file.


       The  application  resource  file specifies the resources an application
       uses, and how the application is started.  There  must  always  be  one
       application  resource  file called for each application
       Application in the system.

       The file is read by the application controller when an  application  is
       loaded/started.  It  is  also  used  by  the functions in systools, for
       example when generating start scripts.


       The application resource file should be  called  where
       Application  is the name of the application. The file should be located
       in the ebin directory for the application.

       It must contain one single Erlang term, which is called an  application

       {application, Application,
         [{description,  Description},
          {id,           Id},
          {vsn,          Vsn},
          {modules,      Modules},
          {maxP,         MaxP},
          {maxT,         MaxT},
          {registered,   Names},
          {included_applications, Apps},
          {applications, Apps},
          {env,          Env},
          {mod,          Start},
          {start_phases, Phases}]}.

                    Value                Default
                    -----                -------
       Application  atom()               -
       Description  string()             ""
       Id           string()             ""
       Vsn          string()             ""
       Modules      [Module]             []
       MaxP         int()                infinity
       MaxT         int()                infinity
       Names        [Name]               []
       Apps         [App]                []
       Env          [{Par,Val}]          []
       Start        {Module,StartArgs}   undefined
       Phases       [{Phase,PhaseArgs}]  undefined
         Module = Name = App = Par = Phase = atom()
         Val = StartArgs = PhaseArgs = term()

       Application is the name of the application.

       For  the  application controller, all keys are optional. The respective
       default values are used for any omitted keys.

       The functions in systools require more information. If they  are  used,
       the following keys are mandatory: description, vsn, modules, registered
       and applications. The other keys are ignored by systools.

           A one-line description of the application.

           Product identification, or similar.

           The version of the application.

           All modules introduced by this application. systools uses this list
           when  generating  start scripts and tar files. A module can only be
           defined in one application.

           Deprecated - will be ignored
           The maximum number of processes allowed in the application.

           The maximum time in milliseconds that the application is allowed to
           run.  After  the  specified time the application will automatically

           All names of registered  processes  started  in  this  application.
           systools  uses  this  list to detect name clashes between different

           All applications which are included by this application. When  this
           application is started, all included application will automatically
           be loaded, but not started, by the application  controller.  It  is
           assumed  that the topmost supervisor of the included application is
           started by a supervisor of this application.

           All applications which must be started before this  application  is
           allowed  to be started. systools uses this list to generate correct
           start scripts. Defaults to  the  empty  list,  but  note  that  all
           applications have dependencies to (at least) kernel and stdlib.

           Configuration  parameters  used  by the application. The value of a
           configuration     parameter     is     retrieved     by     calling
           application:get_env/1,2.  The  values  in  the application resource
           file can be overridden by  values  in  a  configuration  file  (see
           config(5)) or by command line flags (see erl(1)).

           Specifies the application callback module and a start argument, see

           The mod key is  necessary  for  an  application  implemented  as  a
           supervision  tree,  or the application controller will not know how
           to start it. The mod key can be omitted  for  applications  without
           processes, typically code libraries such as the application STDLIB.

           A  list  of  start phases and corresponding start arguments for the
           application. If this key is present, the application master will  -
           in  addition  to  the  usual  call  to  Module:start/2  - also call
           Module:start_phase(Phase,Type,PhaseArgs)  for  each   start   phase
           defined by the start_phases key, and only after this extended start
           procedure will application:start(Application) return.

           Start phases may be used to synchronize startup of  an  application
           and  its  included  applications. In this case, the mod key must be
           specified as:

         {mod, {application_starter,[Module,StartArgs]}}

           The application  master  will  then  call  Module:start/2  for  the
           primary  application, followed by calls to Module:start_phase/3 for
           each start phase (as defined for the primary application) both  for
           the  primary  application and for each of its included application,
           for which the start phase is defined.

           This implies that for an included application,  the  set  of  start
           phases  must  be  a  subset  of  the  set of phases defined for the
           primary application.  Refer  to  OTP  Design  Principles  for  more


       application(3erl), systools(3erl)