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 release dependencies. The dialyzer can be skipped using the skipDialyzer parameter.

• 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. Example: If artifact id is release the environment variable ${RELEASE_TOP} must be set.

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 not upload the application's resource files. The modules will be purged once as if c:c/1 would have been called on a shell.