Configuration and Usage

Introduction

The EAR plugin allows to generate automatically the descriptor deployment, e.g. application.xml. This generation is already customized by the goal's parameters, see the goals description.

Configuring the EAR Plugin

The configuration of the EAR Plugin is not any different with the configuration of the other plugins. The configuration should be similar to:

<project>
  [...]
  <build>
    [...]
    <plugins>
      [...]
      <plugin>
        <artifactId>maven-ear-plugin</artifactId>
        <configuration>
          <!-- configuration elements goes here -->
        </configuration>
      </plugin>
   [...]
</project>

When configuring the EAR Plugin in your pom.xml, you do not declare any <executions> elements in it because it is always invoked at least once during the package phase of an ear project.

Executing and Generating your EAR Package

The EAR Plugin replaces the Jar Plugin when your project <packaging> is ear. So to generate your EAR package, you need only call the package phase like so:

mvn package

Advanced Configuration

Any EAR module might be further customized as follows:

  • bundleDir: the directory in the EAR structure where the artifact will be stored.
  • bundleFileName: the name of the artifact in the EAR structure.
  • uri: the complete path in the EAR structure for the artifact.
  • excluded: excludes the artifact from the generated ear.
  • unpack: unpack the artifact in the generated ear.

The context root of a Web module might be customized using the contextRoot parameter.

Please note that third party libraries (i.e. JarModule) are not included in the generated application.xml (only ejb-client should be included in a java entry). However, a jar dependency could be included in the generated application.xml by specifying the includeInApplicationXml flag.

It is also possible to specify a default bundle directory for all third party libraries by specifying the defaultLibBundleDir parameter.

The security settings might be specified under the security parameter.

The artifact's types that should be unpacked by default can be specified using the unpackTypes parameter

The file name mapping to use for artifacts stored in the EAR can be specified using the fileNameMapping parameter. Valid values for this parameter are standard (default) and full. By specifying full as file name mapping, artifacts are prefixed by the groupId where dots have been replaced by dashes.

For more information on EAR modules, please see the modules configuration page.

You can take a look at the examples for more information on these advanced configurations.

JBoss support

The EAR plugin can generate the jboss-app.xml automatically. To do so, the 'jboss' element must be configured and takes the following child elements:

  • version: the targeted JBoss version to use, 3.2, 4 or 4.2 (the default is 4).
  • security-domain: the JNDI name of the security manager (JBoss 4 only)
  • unauthenticated-principal: the unauthenticated principal (JBoss 4 only)
  • loader-repository: the name of the UnifiedLoaderRepository MBean to use for the ear to provide ear level scoping of classes deployed in the ear
  • jmx-name: the object name of the ear mbean.
  • module-order: specify the order in which the modules specified in the application.xml file gets loaded (JBoss 4.2 only)
  • data-sources: specify the desired data source(s) to add into the jboss-app.xml, usage is as follows:
    <configuration>
      <jboss>
        [...]
        <data-sources>
          <data-source>main-ds.xml</data-source>
          <data-source>config/secondary-ds.xml</data-source>
          [...]
        </data-sources>
      </jboss>
    </configuration>

Hibernate archives (HAR) and Service archives (SAR) will be recognized automatically and added the the jboss-app.xml file.

You can take a look at the examples for more information on the JBoss support.