The Cobertura plug-in can be invoked at the command line in the module directory by running the command:

      mvn cobertura:cobertura

When this command is executed, Maven will invoke the Cobertura plug-in so it can instrument the source code and measure test coverage. This plug-in will compile the instrumented code separately and generate the compiled instrumented classes under the 'target/generated-classes' directory. The coverage reports will be typically generated under the 'target/site/cobertura' directory as shown in Figure 9.

The report can be viewed by opening 'index.html' in a browser as shown in Figure 10.

The line coverage is only 48% since we have only one simple test case. However, coverage can be increased by inspecting the class in the report to check which methods and lines aren't covered and by adding sufficient cases to test different logical conditions so that almost all lines of code get executed. Typically a code base is considered to be under good test coverage if the line coverage is more than 80%, although achieving upwards of 90% isn't that hard with the appropriate test setup.

Packaging and Installing 'ejb' Artifacts
Listing 3 is the final modified POM file for 'ejb' module and Listing 4 is the 'ejb.xml' file that should be under the 'src/main/resources/META-INF' directory.

To deploy an 'ejb' artifact to a local repository, right-click on the module's POM file in Eclipse and then in the 'Run As' options select 'Maven2 install.' Maven will execute 'maven-ejb-plugin' to install both EJB JAR and EJB client in the local repository along with POM information as shown in Figure 11.

Setting Up a 'web' Module
The creation of 'web' modules is fairly simple using Maven. Maven provides a 'maven-archetype-webapp' archetype to create the Web application project directory structure. We'll use 'maven-archetype-webapp' to create a 'web' module. To do this, go to the 'EmployeeInfo' directory on the command prompt and execute the Maven command:

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp
-DgroupId=com.somecompany -DartifactId=web -Dversion=1.0

Maven creates the 'Web' module directory structure as shown in figure 13. Note that 'maven-archetype-webapp' creates a 'web/src/main/webapp' directory containing a default 'index.jsp' page and a 'WEB-INF' directory containing a 'web.xml' file. Even though an 'src/main/java' directory isn't created, any source code needed by the Web application can be put in that directory. Similarly any JUnit test cases for the Web application can be put in the 'src/test/java' directory. Note that 'maven-archetype-webapp' creates a 'web/src/main/resources' directory that can be used for storing any application resources such as properties files that will be needed in the runtime classpath (see Figure 12).

Refresh the 'EmployeeInfo' project in Eclipse and update the Maven source directories. As was the case earlier, we will use Maven's project inheritance model to remove any redundant version, group, and common dependency information from the 'web' POM file. Note that by default POM file has a packaging type set to 'war.'

The 'web' module is a very simple Web application that consists of an index page containing a simple HTML form. The form has a text field to input Employee IDs. When the form is posted with an Employee ID, the HTTP request is received and processed by a Struts action. The Struts action retrieves the employeeId, looks up the stateless session EJB 'GetEmployeeInfoBean,' and invokes the 'getEmployeeInfo' method to retrieve the Employee details.

The Struts action then stores the Employee details Castor object as a request attribute and forwards the request to the 'employeeInfo.jsp' page. The 'employeeInfo.jsp' page uses JSTL tags to render the Employee information. This description implies that the 'web' module will have dependencies on 'ejb,' 'xmlBinding,' 'castor,' 'struts,' and 'jstl' artifacts. However, since the 'ejb' module depends internally on 'xmlBinding' and since 'xmlBinding' depends on the'castor' artifact, it's sufficient to include dependency on the 'ejb' artifact without any need to explicitly include dependencies on 'xmlBinding' and 'castor' since Maven will transitively resolve dependencies. We'll add dependencies on the 'struts-1.2.4.jar' and 'jstl-1.1.2.jar' artifacts in the POM file. Note that this module also needs compile time servlet and EJB specification classes. We'll add dependencies on 'geronimo-spec-j2ee-1.0-M1.jar' with a scope value of 'provided'.

Listing 5 is the modified POM.

Note the highlighted dependency declaration for the 'ejb' artifact. We included the 'type' element with a value of 'ejb-client' to indicate to the Maven dependency manager to include the EJB client JAR instead of an EJB main JAR as a dependency. As described earlier in the context of the 'ejb' module, we explicitly forced the 'maven-ejb-plugin' to create a client JAR along with a main EJB JAR. As a result of the above declaration, the Maven dependency manager will include 'ejb-1.0-client.jar' in the Web application classpath.

We'll add the source code, JSPs, 'web.xml,' and 'struts-config.xml' files for the 'web' module as shown in Figure 13.

Packaging and Installing the 'web' Module
To deploy a 'web' artifact to the local repository, right-click on the module's POM file in Eclipse and then in 'Run As' options, select 'Maven2 install.' Maven will compile, package, and install the 'web-1.0.war' artifact in the local repository along with the POM information.

Setting Up an 'ear' Module
Setting up an 'ear' module is fairly easy. We'll use the command below to create a basic Maven project in the 'EmployeeInfo' directory and edit the POM to change the packaging type to 'ear' and remove redundant group, version, and dependency information since such information is inherited from parent POM.

mvn archetype:create -DgroupId=com.somecompany -DartifactId=employeeInfoEAR -Dversion=1.0

To build an EAR file, the first step would be to add 'maven-ear-plugin' to the POM file. The EAR plug-in replaces the Jar plug-in when the project <packaging> is set to 'ear.' This plug-in can generate an 'application.xml' file based on the plug-in configuration information provided in the POM. The plug-in configuration provides the ability to add different J2EE modules such as RAR, EJB, JAR, and WAR. Note that the 'maven-ear-plugin' will include different modules in the final EAR file that are declared under the <modules> element in the plug-in configuration using a module-specific configuration element such as <rarModule>. All the modules that will be included under the plug-in configuration should be declared as dependencies in the POM file. The following are the common configuration options available for the module-specific configuration element:

• groupId - Sets the groupId of the current artifact you want to configure.
• artifactId - Sets the artifactId of the current artifact you want to configure.
• classifier - Sets the classifier of the current artifact you want to configure if multiple artifacts under the ear matches the groupId/artifact.
• bundleDir - Sets the location of current artifact inside the ear archive. If not set, the current artifact will be packaged in the root of the archive.
• bundleFileName - Sets the new name for the current artifact inside the ear archive. If not set, the artifact's filename in the repository is used.
• excluded - Set to true to exclude the current artifact from being packaged into the ear archive. Default is false.
• uri - Sets the uri path of the current artifact within the ear archive. Automatically determined when not set.
• unpack - Set to true to unpack the current artifact into the ear archive according to its uri. Default is false.

The inclusion of the WAR module is similar as well using <webModule>. However, <webModule> provides the additional configuration option 'contextRoot'. This can be used to set a Web application context root name different from the actual Web application artifact name. We'll use this option in our 'Web' module to set the context root as '/employeeInfo'. We'll also explode this artifact in the EAR by setting the 'unpack' configuration option to true. The modified POM is shown in Listing 5. For more information on the 'maven-ear-plugin,' go to http://maven.apache.org/plugins/maven-ear-plugin/.

Packaging & Installing an 'ear' Module
To deploy an 'ear' artifact to the local repository, right-click on the module's POM file in Eclipse and, in 'Run As' options, select 'Maven2 install.' Maven will compile, package, and install the 'employeeInfoEAR-1.0.ear' artifact in the local repository along with the POM information. The same result can be achieved by running the 'mvn clean install' command from the command prompt inside the 'employeeInfoEAR' directory. Note that at any given point of time, the entire application can be built and installed to the local repository by executing an 'mvn install' command from within the parent 'EmployeeInfo' directory. This can also be achieved by right-clicking on the parent 'EmployeeInfo' POM file in Eclipse and, in the 'Run As' options, selecting 'Maven2 install.' When this is invoked, Maven will build and install each individual child module found in the parent POM.

Conclusion
In this article, we attempted to explain the working nature of Maven 2 through an example. We showed how it can be used in typical J2EE application development. Maven 2 is certainly a powerful tool that significantly simplifies and standardizes build process management. By following a set of standard principles and core competencies, Maven 2 considerably increases a software developer's productivity by eliminating the grunt work typically incurred during application development. Maven 2 reuses build logic in the form of easy-to-use plug-ins and offers a cornucopia of useful features for build process management.

In this article, we only scratched the surface of Maven 2's capabilities and software developers can definitely take advantage of many other Maven 2 features like continuous integration support and project communication management. The more one uses Maven 2, the greater one appreciates its merits.

Acknowledgements
We'd like to thank our managing directors Bill Bernahl and Gail Dielman for their support and inspiration in writing this article. Our special thanks to our colleagues Todd August, Saya Alur, Huachao Li, and Prasad Nagu for spending their time reviewing the article, patiently exercising the example, and providing valuable feedback. Without their support, the article would not have been finished. Thanks to the rest of our team members who inspired us to write this article.

• An Introduction to Maven - Part I
• An Introduction to Maven - Part II
• An Introduction to Maven - Part III