Mavenbook.org

To illustrate this functionnality, let's take a working example implemented in the EAR plugin. An ear module represents a particular artifact to bundle in the EAR file: it is identified by a groupId and an artifactId used to retrieve the Artifact object from the project's dependencies. The base contract of such a module is defined by the EarModule interface which is implemented by:

• JavaModule
• EjbModule
• EjbClientModule (extending JavaModule)
• WebModule
• RarModule

/**
 * The ear modules configuration.
 *
 * @parameter
 */
private EarModule[] modules;

Now let's say we want to specify a custom context root for web modules. To do so we define a property in the WebModule's implementation:

public class WebModule
    extends AbstractEarModule
{

    private String contextRoot;

    public WebModule() 
    {
      super();
    }

    [etc...]  
}

Users could define the following configuration:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-ear-plugin</artifactId>
      <configuration>
        [etc...]
        <modules>
          <webModule>
            <groupId>artifactGroupId</groupId>
            <artifactId>artifactId</artifactId>
            <contextRoot>/custom-context-root</contextRoot>
          </webModule>
          [etc...]
        </modules>
      </configuration>
    </plugin>
  </plugins>
</build>

Note that the name of the element defines the implementation of the EarModule interface to use. Common settings could be placed in a common class, AbstractEarModule for instance.