This Mojo copies the private resources to the AbstractErlangMojo.targetPriv directory. Default source folders for private resources are AbstractErlangMojo.srcMainPriv and AbstractErlangMojo.srcMainResourcesPriv.

This Mojo runs the erlang dialyzer tool on a complete release found in AbstractErlangMojo.targetLib. The dialyzer can be skipped using the useDialyzer paramter in the projects pom. Since this Mojo is called in order to check a complete release it is run over all release dependencies.

This Mojo packages all application artifacts into a single .tar.gz package. This includes .beam files, the .hrl include files, SNMP resources, private data from the priv and resources directories and non-erlang sources.

Besides that this Mojo also copies the erlang application resource file. In order to manage the project over the project pom there is the possibility to let the Mojo automatically fill in values from the project pom into the .app file. This can be done by using one of the supported variables into the application resource files. Below is a list of supported variables and their substitutions:

• ${ARTIFACT}: the projects artifact id (atom)
• ${DESCRIPTION}: the projects description (string)
• ${ID}: the projects id (string)
• ${VERSION}: the projects version (string)
• ${MODULES}: all compiled .beam files found in the target ebin folder (list)
• ${REGISTERED}: all registered names, based on the -registered(Names). attribute retrieved from the compiled .beam files (list)

In case there is no application resouce file specified the Mojo will generate a default .app file which looks like this:

{application, ${ARTIFACT},
  [{description, ${DESCRIPTION}},
   {id, ${ID}},
   {vsn, ${VERSION}},
   {modules, ${MODULES}},
   {maxT, infinity},
   {registered, ${REGISTERED}},
   {included_applications, []},
   {applications, []},
   {env, []},
   {mod, undefined},
   {start_phases, []}]}.

The resulting application resource file as well as the application upgrade file will be checked for plausability regardless if generated or not. This is done by checking the application version against the project version, checking the application modules against the found compiled modules as well as checking the application's start module.

This Mojo prepares the packaging of a release .tar.gz package by creating the release upgrade/downgrade scripts as well as the boot and start scripts. The scripts are created using the erlang systools modules make_relup and make_script functions.

The builds can be customized by passing user options through the scriptOptions and relupOptions parameters in the specific project pom. In order to manage the project over the project pom there is the possibility to let the Mojo automatically fill in values from the project pom into the .rel file. This can be done by using one of the supported variables into the release file. Below is a list of supported variables and their substitutions:

• ${ARTIFACT}: the projects artifact id (atom)
• ${VERSION}: the projects version (string)
• ${APPLICATIONS}: a list of the project dependencies application and version tuples
• ${APPLICATION_NAME}: will be replaced by a string representing the available application version on this host

In case there is no release file specified the Mojo will generate a default .rel file which looks like this:

{release,
  {${ARTIFACT}, ${VERSION}},
  {erts, ${ERTS}},
  [{kernel, ${KERNEL}}, 
   {stdlib, ${STDLIB}}] ++ ${APPLICATIONS}}.

The resulting release file will be checked for plausability regardless if generated or not. This is done by checking the release version against the project version and checking all dependency versions against the application versions in the release file.

In order to create the release downgrade/upgrade script the Mojo also needs a list of versions to upgrade from or to downgrade to. If the user chooses to not specify both lists the release script generation will be skipped.

TODO The generation of relup files has not yet been tested.

Utility goal that will setup a new Erlang/OTP Maven project, creating the basic resources and folders required, from a best practice point of view.

This will typically replaces the functionality given by a Maven archetype, checking and creating any missing resource:

• src/main/erlang
• src/main/erlang/[artifactId].app
• src/main/include
• src/main/priv
• src/test/erlang
• src/test/include
• src/site/site.xml
• src/site/apt/index.apt[.vm]
• src/changes/changes.xml