Provided by: erlang-manpages_13.b.3-dfsg-2ubuntu2_all bug

NAME

       app - Application resource file.

DESCRIPTION

       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 Application.app 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.

FILE SYNTAX

       The application resource file should be  called  Application.app  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
       specification:

       {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.

          description
             A one-line description of the application.

          id Product identification, or similar.

          vsn
             The version of the application.

          modules
             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.

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

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

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

          included_applications
             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.

          applications
             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.

          env
             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(4)) or by command line flags (see erl(1)).

          mod
             Specifies the application callback module and a  start  argument,
             see application(3erl).

             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.

          start_phases
             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
             information.

SEE ALSO

       application(3erl), systools(3erl)