This Mojo will generate an application upgrade file template for an application. In order to do so all available non-SNAPSHOT versions of the project will be resolved (also from remote repositories). All versions smaller than the current version will be included in the generation. The resulting application upgrade file's location will be prompted on success as well as its content.

The generation algorithm is outlined in the following description:

• Find added modules and add a {load_module, Module} statements for them.
• Find updated modules and invoke the GetAppupDirectiveScript on them.
• Find deleted modules and add a {delete_module, Module} statements for them.

The GetAppupDirectiveScript works as described below:

• Add a {update, Module, supervisor} statement if Module is a supervisor.
• Add a {update, Module} statement if Module exports code_change/3.
• Add a {load_module, Module} statement if Module does not meet the previous conditions.

ISSUE If a test purges or unloads a module to do coverage for, the coverage compilation information will be gone and the coverage report will fail.

This Mojo runs the erlang dialyzer tool on the project sources as well as the project includes. This means dialyzer will run over the complete project code (excluding test modules).

The dialyzer can be skipped using the skipDialyzer parameter. Additionally, the user can choose to run dialyzer also on the projects dependencies using the dialyzerWithDependencies parameter. This will be done by default.

• erlang source files (*.erl)
• erlang include files (*.hrl)
• edoc overviews (overview.edoc)
• resources (*)

  mvn erlang:help -Ddetail=true -Dgoal=<goal-name>

This Mojo packages all application artifacts into a single .tar.gz package. This includes .beam files, the .hrl include files and private data from the priv directory.

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 and .appup files. 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)
• ${APPLICATIONS}: all dependency applications of the project as configured in the project's pom.xml (string)

The resulting application resource file as well as the application upgrade file will be checked for plausability.

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 replace the functionality given by a Maven archetype, checking and creating any missing resource. Regarding Erlang/OTP applications this could be:

• source folder
• application resource file [artifactId].app
• application upgrade file [artifactId].appup
• include folder
• priv folder
• test source folder
• test include folder
• test priv folder

Regarding Erlang/OTP releases this could be:

• release file [artifactId].rel
• system configuration sys.config

By default some extras for project management are also generated:

• site folder with site.xml
• apt source folder with index.apt[.vm]
• changelog folder with changes.xml

The default application resource file will look like (this would be sufficient for library applications):

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

The default application upgrade file will look like:

{${VERSION}, [EDIT HERE], [EDIT HERE]}.

The default release file will look like:

{release,
 {${ARTIFACT}, ${VERSION}},
 ${ERTS},
 ${AUTODEPS}}.

The default release upgrade file will look like:

{${VERSION}, [EDIT HERE], [EDIT HERE]}.

The default system configuration file will look like:

[].

This Mojo creates a target system release package .tar.gz according to the official documentation. If there's no sys.config file found a default empty one will be included.

The resulting target system depends on a correct root directory configuration. The plug-in will change the scripts to check for the ${ARTIFACTID_TOP} (upper case) environment variable. This variable must be set by the user to guarantee a proper system behaviour. Custom arguments like node name or cookie can be set by using the standard erlang environment variables $ERL_AFLAGS, $ERL_ZFLAGS or $ERL_FLAGS. If you wish to run several releases on the same node the variable ${ ARTIFACTID_FLAGS} (upper case) environment variable could be used alternatively to ERL_FLAGS.

Example: If artifact id is release the environment variable ${RELEASE_TOP} must be set. Arguments could be specified by setting ${RELEASE_FLAGS} like that RELEASE_FLAGS="-sname some_node -setcookie some_cookie"

Note: The resulting target system is highly system dependent since it contains the erlang emulator (C code) from the backend nodes erlang installation.

Note: This mojo is currently working but still in experimental stage.

• FIXME not supported on Microsoft Windows

This Mojo uploads an application's modules compiled for test execution and the application's tests onto a remote node. This will also upload the application's resource files making them available to the remote node using code:priv_dir/1. The modules will be purged once as if c:c/1 would have been called on a shell.