Provided by: erlang-manpages_11.b.5-1_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
              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(3).

             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(3), systools(3)

AUTHORS

       Martin Bjorklund - support@erlang.ericsson.se
       Gunilla Arendt - support@erlang.ericsson.se