Provided by: erlang-manpages_18.3-dfsg-1ubuntu3.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},
          {runtime_dependencies, RTDeps}]}.

                    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}   []
       Phases       [{Phase,PhaseArgs}]  undefined
       RTDeps       [ApplicationVersion] []
         Module = Name = App = Par = Phase = atom()
         Val = StartArgs = PhaseArgs = term()
         ApplicationVersion = string()

       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.

   Warning:
       The  RTDeps type was introduced in OTP 17.0 and might be subject to changes during the OTP
       17 release.

         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(5)) 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.

         runtime_dependencies:
           A  list of application versions that the application depends on. An example of such an
           application  version  is  "kernel-3.0".  Application  versions  specified  as  runtime
           dependencies  are minimum requirements. That is, a larger application version than the
           one specified in the dependency satisfies the requirement. For information on  how  to
           compare  application  versions  see  the  documentation  of  versions  in  the  system
           principles guide. Note that the application version specifies a source  code  version.
           An  additional  indirect  requirement  is  that  installed  binary  application of the
           specified version has been built so that it is compatible with the rest of the system.

           Some dependencies might only be required in specific runtime scenarios.  In  the  case
           such   optional  dependencies  exist,  these  are  specified  and  documented  in  the
           corresponding "App" documentation of the specific application.

     Warning:
         The runtime_dependencies key was introduced in OTP 17.0. The type of its value might  be
         subject to changes during the OTP 17 release.

     Warning:
         All runtime dependencies specified in OTP applications during the OTP 17 release may not
         be completely correct. This is actively being worked on. Declared  runtime  dependencies
         in OTP applications are expected to be correct in OTP 18.

SEE ALSO

       application(3erl), systools(3erl)