Identified Practices

Writing Maven Plugins

[P1.1] Name the Mojo class <Operation name>Mojo extends AbstractMojo. Always use the javadoc style of Mojo annotation as follows:

/**
 * ...
 * @author Rusi Popov
 */
@Mojo(name="<goal name of this mojo in kebab case>",
      defaultPhase=LifecyclePhase.COMPILE
)
@Execute(phase=LifecyclePhase.COMPILE)
public class <Purpose of this Mojo>Mojo extends CompilationContext ...

[P1.2] Always use the java Mojo annotations for parameters:

/**
 * The file to produce
 */
@Parameter(required=true)
private File targetFile;

/**
 * Selection of all modelant Templates below sourceDirectory
 */
@Parameter
private FileSet fileSet;

/**
 * Where to generate the API sources
 */
@Parameter(property="project.build.sourceDirectory", required=true)
private File sourceDirectory;

/**
 * Where the work files are located
 */
@Parameter(property="project.build.directory", required=true)
private File workDirectory;

[P1.3] Mojo logging - use the Maven-provided logging mechanism:

getLog().warn("warning...");
...
if (getLog().isDebugEnabled()) {
  getLog().debug("debug...");
}

[P1.4] When including the mojo in artifacts generated by modelant, refer both the goal name and execution phase (no matter the phase has a default) to make the binding explicit. Then anyone else would not need to read the Mojo to identify when it is activated:

<executions>
  <execution>
    <phase>generate-sources</phase>
    <goals>
      <goal>generate-model-api</goal>
    </goals>
    <configuration>
      <metamodelFile>${metamodelUrl}</metamodelFile>
    </configuration>
  </execution>
</executions>

[P5] When including the Mojo in manually written artifacts it is enough to provide just the goal name (the phase is by default, no need of <id>,..):

<executions>
  <execution>
    <goals>
      <goal>compile-templates</goal>
    </goals>
  </execution>
</executions>

Maven will use the default phase from the [class’ annotation to bind the plugin](http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Complex_Objects Mapping Complex Objects in Maven).

Java Libraries as Dependencies in Maven

[P2.1] As of Maven Dependencies, when referring the JAVA platform tools or other platform libraries as dependencies (not published as Maven artifacts) use:

• system scope
• systemPath defined through an explicitly set property or Java system property (like ${java.home}), but not as an environmental one, as env.XYZ may not exist by the moment of running:

For example:

<dependency>
  <groupId>java.tools</groupId>
  <artifactId>dt</artifactId>
  <version>1.8</version>
  <scope>system</scope>
  <systemPath>**${java.home}**/../lib/tools.jar</systemPath>
</dependency>

Note: This definition causes problems under Eclipse with default setup with default Java setup under Windows, because of the spaces in the path. Therefore apply the [[modelant - migration to maven#Eclipse_Setup_Procedure_for_Windows|Eclipse Setup Procedure for Windows]]