- Web Project Types and J2EE Applications
- Advanced Web Projects
- Example Projects
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Example Projects
It is time to discover how you can create some interesting projects. These best practices provide different styles of projects for Web and J2EE development. You can extend and customize these examples to fit your needs. The examples we'll discuss are a basic enterprise application, dividing a Web module into multiple projects, and using Maven for Web application development.
Basic Enterprise Application
Using the J2EE application deployment specification as a template, you will create an enterprise application with multiple modules. This is recommended if you do not have a compelling reason to do it another way. These projects map to the J2EE specification in a straightforward way and can be created using wizard defaults. Adherence to standards reduces the behavioral discrepancies between the runtime and the development environments.
In this example, each architectural application layer will correspond to a project. For example, the presentation layers will correspond to a dynamic Web project with a Web application module and the business logic layer to an EJB project with an EJB module. The enterprise application project will be used to assemble the modules as a single coherent unit.
To create this structure, you will use a J2EE Enterprise Application Project (see Figure 6.28). The EAR project has two modules: LeaguePlanetWebProject, a Web application module; and LeaguePlanetEJBProject, an EJB module. The Web application module is going to be a dynamic Web project with the same name. The EJB module is divided into an EJB project and the EJB client project. The EJB client JAR is a Java utility project named LeaguePlanetEJBClientProject.
)
Figure 6.28 Module Dependencies for League Planet Application
To demonstrate the use of Web application libraries, the Web application will use the Struts MVC framework. In order to use Struts, all Struts and supporting libraries, that is, struts*.jar, commons*.jar, jakarta*.jar, log4j.jar, and antlr.jar, are kept in the WEB-INF/lib directory. The Struts configuration file, struts-config.xml, is in the WEB-INF directory. The business model for League Planet is provided by the EJBs. The Web application delegates the business behavior to this layer.
To create an EAR project with this structure, do the following:
- Start as we described earlier in this chapter to create a new Enterprise Application Project. Name it LeaguePlanetEar. Select the default facets, continue to the J2EE Modules page, and click Finish to create an empty EAR. In the next steps you will create the Web and EJB projects.
- Repeat the steps we described earlier in this chapter to create a new Dynamic Web Project. Name it LeaguePlanetWebProject. Choose the LeaguePlanetEar as the EAR for the Web project (see Figure 6.29). Continue to the other pages to select the default facets, and click Finish to create the Web project. The EAR project will be automatically updated to reflect the addition of the new Web module.
Figure 6.29 Web Project Added to an EAR
To do this step, you must have the Struts framework installed someplace on your machine. You can obtain Struts from
Import all the Struts libraries and their supporting libraries into
WebContent/WEB-INF/lib
Refer to the Struts documentation for the exact list of libraries. Once the JARs are copied into the lib folder, they will be automatically added to the build path under the Web App Libraries category (see Figure 6.30).
Figure 6.30 Web App Library
- Repeat the steps we described earlier in this chapter to create a new EJB project. Name it LeaguePlanetEJBProject. Choose the LeaguePlanetEar as the EAR for the EJB project (see Figure 6.31). You can choose one of the default facet configurations for development, such as the EJB Project with XDoclet. You do not need to change the default choices. If you do choose one, you should make sure that your workspace is set up to use it (that is, the XDoclet settings are valid). Click Next to go to the other pages to select the default facets. Click Next to go to the EJB Module page.
Figure 6.31 EJB Project Added to an EAR
- The Web application will be a client of the EJB module. Create an EJB client module named LeaguePlanetEJBClientProject (see Figure 6.32). Click Finish to create the EJB and EJB client projects. The EAR project will be automatically updated to reflect the addition of the two new modules.
Figure 6.32 EJB Client Module
- WTP updates the EAR project and the deployment descriptor, application.xml (see Figure 6.33).
Figure 6.33 Project Explorer—EAR Project
)
)
)
)
)
To create these projects, you used the same wizards described earlier in this chapter.
Web Application Module Uses EJB Client
You need to make sure that the dependency between the Web application module and the EJB client is set. The Web application is a client of the EJB module. You need to describe this dependency. Remember that you created an EJB client module named LeaguePlanetEJBClientProject. You will add this module to the J2EE dependencies in the Web project. Select the Web project in the Project Explorer, right click and invoke the Properties menu item. Select the J2EE Dependencies page. In this tab, select LeaguePlanetEJBClient from the list (see Figure 6.34).
)
Figure 6.34 Dependency to EJB Client Module
Later, you can extend this model by adding more Web projects—an administration site, for example. The business model can be extended with more EJBs.
Dividing a Web Module into Multiple Projects
Size, structure, and the geographical and sociological aspects of a development team are significant factors in determining the project layout. When these are important to a project, they can determine the structure. The key constraints for this template are the manageability and divisibility of work. Manageability relates to aspects such as ownership of code, development responsibilities and tasks, configuration and version control, integration, and release management. Divisibility relates to dividing the work between members of the development team.
In this example, you will extend the project structure described in the previous example. LeaguePlanetWebProject is a large Web application module. It will contain many large, loosely coupled subsystems. League management, player management, sponsorship, and advertising are some of these subsystems that will be developed by different teams. You will divide and manage subsystems as separate projects. Each subsystem can be released on different schedules. You will therefore start by dividing the Web module into two projects (see Figure 6.35). You can increase the number of subsystems following the same pattern later on. The dynamic Web project in the previous example contains the Web application module and will have common Web components such as menus, navigation bars, and so forth. There is a new subsystem for league management. This is a Java utility project on steroids. The league management module has its own presentation layer with JSPs and Struts configuration files in addition to its own Java classes.
)
Figure 6.35 Dividing a Web Module into Multiple Projects
To create this structure, you will need to create a new basic Java Utility Project named LeaguePlanetManagementWebProject. Java utility projects can be used to refactor reusable components of applications into separate projects. J2EE module dependencies will help assemble these components automatically.
To create the Java Utility Project and divide the module, the following steps must be performed:
- Create a new Java Utility Project using the wizard.
- Add the Web application libraries to its build path.
- Add the utility project to the list of J2EE dependencies for the Web project.
- Create a new WebContent folder in the utility project and add this to the structural model.
Do the following:
- In the Project Explorer view, right click and invoke the New
Other J2EE menu item (see Figure 6.36). Select Utility Project.
Click Next. The New Java Utility Project wizard opens (see Figure 6.37).
Figure 6.36 Select Wizard
Figure 6.37 New Java Utility Project
- Enter LeaguePlanetManagementWebProject for the project name. Use the same target runtime for all your projects. Use the default configuration. Click the Next button. The Project Facets selection page is displayed (see Figure 6.38).
Accept the defaults here and click Finish. WTP creates the empty utility project.
Figure 6.38 Select Project Facets
- You need to add this submodule to the J2EE dependencies of the Web project. To do this, select LeaguePlanetWebProject in the Project Explorer, right click, and invoke the Properties menu item. Select the J2EE Dependencies page. In this page, go the Web Libraries tab and add LeaguePlanetManagementWebProject from the list (see Figure 6.39).
Figure 6.39 Web Project Depends on Utility Project
- This is an optional step. The league management module is a part of the Web module, but it may need some external libraries to be on its build path. You can do this by adding the external JARs to the build path of the Java utility project. Select LeaguePlanetManagementWebProject in the Project Explorer, right click, and invoke the Properties menu item. Select the Java Build Path page. Click on the Libraries tab. In this tab, click Add External JARs (see Figure 6.40).
The JAR Selection wizard will open (see Figure 6.41). This wizard allows you to browse your local file system for JARs.
Figure 6.40 Utility Project Java Build Path
Select all the same external libraries, like Struts, that you have used for the Web project here, too. Click Finish. Apply and close the Properties window.
Figure 6.41 Add External JARs Library
- Next you will create a new WebContent folder in the league management project. In the Project Explorer, select LeaguePlanetManagementWebProject, right click, and invoke the File New Folder menu item. The New Folder wizard will open (see Figure 6.42).
Figure 6.42 WebContent Folder
- Enter WebContent as the folder name. Repeat the same process to create a new WEB-INF folder inside the WebContent folder.
- Next you will link the new WebContent folder to the main Web project and add it to the structural model so that publishers will assemble the contents of the WebContent folder from the league management project into the overall project. In the Project Explorer, select LeaguePlanetWebProject, right click, and invoke File New Folder. The New Folder wizard will open (see Figure 6.43).
Figure 6.43 Link to Management WebContent Folder
- Enter Management as the folder name. Click on Link to folder in the file system. Click Browse to select the WebContent folder created in the previous step.
You will need to specify that the WebContent folder in LeagueManagementWebProject gets copied into the deployable Web application module. Currently, there are no nice graphical tools to map these resources, so you will need to edit some files. You need to create the link to the WebContent folder before editing the module definition file. You already completed this step. Therefore, you can modify the XML component file to specify that this content folder is to be published with the Web module. This involves manually editing the
org.eclipse.wst.common.component
definition in the .settings folder. Edit the file as shown in Example 6.3.
)
)
)
)
)
)
)
)
Example 6.3. Modified Web Module Definition
<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="LeaguePlanetWebProject">
<wb-resource source-path="/WebContent" deploy-path="/" />
<wb-resource source-path="/Management" deploy-path="/" />
<wb-resource source-path="/src" deploy-path="/WEB-INF/classes" />
<dependent-module deploy-path="/"
handle="module:/resource/LeaguePlanetEJBProject/
LeaguePlanetEJBProject">
<dependency-type>uses</dependency-type>
</dependent-module>
<dependent-module deploy-path="/WEB-INF/lib"
handle="module:/resource/LeaguePlanetManagementWebProject/
LeaguePlanetManagementWebProject">
<dependency-type>uses</dependency-type>
</dependent-module>
<property name="context-root" value="LeaguePlanetWebProject" />
<property name="java-output-path" value="build/classes" />
</wb-module>
</project-modules>
You have now split a Web module into multiple projects. The publisher will add the Java classes developed in the league management project as a JAR in the WEB-INF/lib folder to the original Web application module.
The publisher will also assemble any JSPs and additional Struts configuration files from the league management module, as well as all the Web content in this submodule. This content will be deployed with the Web application automatically. After the WAR is created, it will be assembled into the enterprise application as usual. When you are done, the workbench will have projects that look like Figure 6.44.
)
Figure 6.44 Dependent Module in the Project Explorer
Using Maven for Web Application Development
Maven is a software project management and comprehension tool. It started as a tool developed to build the Turbine project at apache.org and quickly spread to other Apache projects. Today, it is used as the main build tool for many of the Java projects at Apache. For an in-depth description of how to use Maven on your project, refer to Maven: A Developer's Notebook [Massol2005] by Vincent Massol and Timothy O'Brien.
Maven is more than a Java build tool. It provides capabilities to make your life easy as a developer. Some of these capabilities are a well-defined project structure, a well-defined development process to follow, and a coherent body of documentation that keeps developers and users informed of what's happening in the project. This is essential in many team projects where there aren't enough people dedicated to the task of building, documenting, and propagating the information about the project. Maven captures the knowledge embedded in people's heads to do these tasks. For example, the development processes of Eclipse and Apache are evolutionary and resulted from the experiences gained from running many projects. This body of knowledge is typically captured in the tools that are used in building projects. Maven provides a standard environment that encourages the use of development and project best practices, and it disseminates this information to project stakeholders.
Following the success of Maven in Apache projects, many teams adopted Maven for their own use, including some J2EE projects. There is a set of J2EE-specific development best practices and processes captured in Maven. The use of Maven to develop a J2EE project enables the transfer of this knowledge. When a new J2EE project starts, it can immediately copy the build tasks and project know-how. The new project reuses the existing tools and conforms to the established practices. Maven does this by providing a framework and templates. For example, by having a common directory structure, developers are instantly familiar with a new project. To quote Aristotle, "We are what we repeatedly do. Excellence is not an act, but a habit."
There are other, less well-known approaches, such as JOFFAD, that also provide generic development frameworks to facilitate, speed up, and normalize J2EE projects. You can read about JOFFAD at
http://joffad.sourceforge.net/structure.html
In Example 6.4 you will use the advanced WTP Web project features to develop a Web application using Maven. Maven has a default, but customizable, process that gets a project started using these J2EE best practices quickly. Although both are named a project, a Maven project is conceptually very different from a WTP project.
Maven and Eclipse have overlapping functionality such as compiling, building, and testing. However, Eclipse is normally used for developer-centric coding, testing, and debugging activities, whereas Maven is used for team-centric build management, reporting, and deployment. The primary purpose of Maven is to create a documented, repeatable, and modeled build process that is inclusive of all these activities. It complements the development activities in Eclipse.
You will start by defining a new Web project and organizing the resources in this project according to the best practices suggested by Maven. See
http://maven.apache.org/reference/conventions.html
for a description of Maven conventions. Maven recommends a standard project directory structure, which is referenced in the Maven Project Object Model (POM). The directory structure of your project will follow Maven conventions (see Example 6.4).
Example 6.4. Maven Project Layout
/LeaguePlanetWebProject +- src/ | +- main/ | | +- java/ | | | +- ...[classes and packages] | | +- resources/ | | +- ... | | +- webapp/ | | | +- web-inf/ | | | | +- classes/ | | | | +- ...[compiled classes] | | | | +- lib/ | | | | +- ...[external libraries] | | | | +- web.xml | | | | +- ... | | | +- ...[other web files] | +- test/ | | +- java/ | | | +- ...[test classes and packages] | | +- resources/ | | +- ... | +- site/ | +- xdoc/ | +- ... +- target/ | +- ... +- pom.xml
All sources are grouped under the src directory. src/main/java contains your primary Java classes and packages. src/test/java contains your classes and packages for unit tests. src/main/webapp, similar to the WTP WebContent folder, contains your Web content, such as the JSP and HTML files, and their supporting resources. src/site/xdoc has sources for the project Web site.
To create the Maven project, do the following:
- Repeat the steps described earlier in this chapter to create a new dynamic Web project named LeaguePlanetWebProject. Select a target runtime and default configuration for facets. Click the Next button to proceed to the Web module settings (see Figure 6.45).
Figure 6.45 Maven Web Module
- The Web Module page lets you specify the directory for Java resources. This is where you will define locations for the Java sources and Web content. Enter src/main/webapp for Content Directory and src/main/java for Java Source Directory. Click Finish.
- WTP creates the Web project, configuration files, deployment descriptor, and so forth.
)
Once the project is created, the structural model for the Web project is defined as Example 6.5.
Example 6.5. Structural Model for Maven-Style Web Project
<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="LeaguePlanetWebProject">
<wb-resource source-path="/src/main/webapp" deploy-path="/" />
<wb-resource source-path="/src/main/java"
deploy-path="/WEB-INF/classes" />
<wb-resource source-path="/src/test/java"
deploy-path="/WEB-INF/classes" />
<property name="context-root" value="LeaguePlanetWebProject" />
<property name="java-output-path" value="build/classes" />
</wb-module>
</project-modules>
Let's review what you accomplished so far. You have created a dynamic Web project using the project layout conventions suggested by Maven (see Figure 6.46).
)
Figure 6.46 Project Explorer—Maven Web Project
Mavenizing the Project
The next step is defining the Maven POM that will automate builds, unit tests, documentation, project reporting, and so on.
The POM is defined by an XML file named pom.xml (see Example 6.6). This file tells Maven everything that it needs to know about your project. Maven has tools that can create skeleton POMs, but we will create the POM from scratch. The snippet shown in Example 6.6 is the start of a POM for your Web application.
Example 6.6. Content of POM
<?xml version="1.0" encoding="UTF-8"?> <project> <modelVersion>4.0.0</modelVersion> <artifactId>leagueplanet</artifactId> <groupId>com.leagueplanet</groupId> <name>LeaguePlanet.com Web Project</name> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <build>[...]</build> <dependencies>[...]</dependencies> </project>
The project artifactId corresponds to the Web application module in your project. Dependencies will define external libraries needed by your Web application. You will use the Struts framework, so struts*.jar and commons*.jar libraries must be present in this list. The build section tells Maven how the Java sources and other resources are organized. Maven project definition allows you to define filters for including or excluding source files.
The build section is quite simple to set up, as shown in Example 6.7.
Example 6.7. Maven Build Section
<?xml version="1.0" encoding="UTF-8"?>
<project>
[...]
<build>
<finalName>${artifactId}-${version}</finalName>
</build>
</project>
The build section can be used to customize your project. Since you used the default location, you do not have to modify anything here. The finalName element automatically constructs the name of the exported WAR from other information provided in the POM.
The dependency section is probably the longest (see Example 6.8).
Example 6.8. Maven Dependencies Section
<?xml version="1.0" encoding="UTF-8"?>
<project>
[...]
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>struts</groupId>
<artifactId>struts</artifactId>
<version>1.2.7</version>
</dependency>
<dependency>
<groupId>struts</groupId>
<artifactId>struts-el</artifactId>
<version>1.2.7</version>
</dependency>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.1.4</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.3</version>
</dependency>
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<version>2.7.5</version>
</dependency>
<dependency>
<groupId>commons-digester</groupId>
<artifactId>commons-digester</artifactId>
<version>1.7</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.7.0</version>
</dependency>
<dependency>
<groupId>oro</groupId>
<artifactId>oro</artifactId>
<version>2.0.8</version>
</dependency>
<dependency>
<groupId>servletapi</groupId>
<artifactId>servletapi</artifactId>
<version>2.3</version>
<scope>compile</scope>
</dependency>
</dependencies>
</project>
Each entry corresponds to an external JAR that is needed by your project. The Struts framework requires a few of these dependencies to be set. Some of these JARs are needed to compile your code; others, such as JUnit, are for testing. The JARs have a scope tag that defines when they are used. For example, by default all Struts JARs will be included with the Web application module, but JUnit has the scope test, so it will not be included.
Remember that Maven gets the libraries defined in the dependencies from a repository. However, for WTP to function properly, you need to keep a copy of these libraries inside the src/webapp/WEB_INF/lib folder instead of the repository. Unfortunately, there is no tool to synchronize the dependencies and libraries.
You have defined the minimal Maven POM to build your Web application. Maven is typically run from the command line. Maven commands are also called goals. Goals are high-level tasks that can include other subtasks. Mevenide is an Eclipse plug-in for Maven that allows you to run Maven goals from the Eclipse IDE. Here you will use the command line. You can build a deployable Web module and a project site by running the maven clean package site goals. The package goal depends on other goals such as compile and test, so Maven will run them automatically. During the build, Maven creates a folder named target to store the generated files. The name and location of the generated files can be modified by additional settings. When you run Maven, you will get an output like that shown in Example 6.9.
Example 6.9. Maven Console Output
C:\workspace\LeaguePlanetWebProject>mvn clean package site [INFO] Scanning for projects... [INFO] --------------------------------- [INFO] Building LeaguePlanet.com Web Project [INFO] task-segment: [clean, package] [INFO] --------------------------------- [INFO] [clean:clean] [INFO] Deleting directory C:\workspace\LeaguePlanetWebProject\target [INFO] Deleting directory C:\workspace\LeaguePlanetWebProject\target\classes [INFO] Deleting directory C:\workspace\LeaguePlanetWebProject\target\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] While downloading servletapi:servletapi:2.3 This artifact has been relocated to javax.servlet:servlet-api:2.3. [INFO] [compiler:compile] Compiling 1 source file to C:\workspace\LeaguePlanetWebProject\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 1 source file to C:\workspace\LeaguePlanetWebProject\target\test-classes [INFO] [surefire:test] [INFO] Setting reports dir: C:\workspace\LeaguePlanetWebProject\target/surefire-reports ------------------------------------------------------------- T E S T S ------------------------------------------------------------- [surefire] Running com.leagueplanet.tests.LeaguePlanetBVTTest [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.01 sec [INFO] [site:site] [INFO] Generate "Continuous Integration" report. [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0 [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0 [INFO] Generate "Dependencies" report. [INFO] Generate "Issue Tracking" report. [INFO] Generate "Project License" report. [INFO] Generate "Mailing Lists" report. [INFO] Generate "Source Repository" report. [INFO] Generate "Project Team" report. [INFO] Generate "Maven Surefire Report" report. [INFO] Generate an index file for the English version. [INFO] ------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------ [INFO] Total time: 11 seconds [INFO] Finished at: Sat May 13 15:48:09 EEST 2006 [INFO] Final Memory: 9M/17M [INFO] ------------------------------------------------------
That is all there is to building a WAR with Maven. You will see from the log that package is a composite goal. In addition to assembling a Web application module using the war goal, it runs the java goal to compile the classes and the test goal to compile and run the tests. Once the build is complete, you can browse the results of the build in the target folder (see Figure 6.47).
)
Figure 6.47 Project Site
So far, you could have done most of this using WTP, without the hassle of setting up Maven in the project. Building Web application modules is something WTP does well, and it does it automatically with minimal effort. But you can get more out of Maven. The next section shows you how to automate testing and reporting on the League Planet project using Maven.
Getting More Out of Maven
Now that you can build the Web application module using Maven, you can add tests and more project information to the POM to find out what more Maven can do.
Unit Tests with Maven
To run unit tests with Maven, you will create JUnit test cases and define required libraries, including JUnit in the project dependencies. Since you defined the JUnit dependencies in the previous section, you can start writing a test in the src/tests/java source folder. In the Project Explorer, select LeaguePlanetWebProject, right click, and invoke the File New Source Folder. The New Source Folder wizard will open (see Figure 6.48).
)
Figure 6.48 Source Folder for Tests
Enter src/test/java as the folder name. Click Finish. A new source folder will be added to the project.
To create a new JUnit test case, invoke the JUnit test case wizard using File New JUnit Test Case, and then enter package and class names, for example, com.leagueplanet.tests and LeaguePlanetBVTTests. Click Finish. The wizard will prompt you to add junit.jar to the project build path if it is not included there already. Accept it to add the JAR.
A new test class will be created at the location shown in Example 6.11.
Example 6.11. Maven Test Directory
/LeaguePlanetWebProject +- src/ | +- test/ | | +- java/ | | | +- com | | | | +- leagueplanet | | | | | +- tests | | | | | | +- LeaguePlanetBVTTests.java | | | | | | +- [...] other unit tests | [...]
Execute the Maven package site goals to run the tests. If you want to run the tests only, you just execute the test goal. Running the Maven test goal creates output as shown in Example 6.12.
Example 6.12. Maven Test Output
[INFO] Scanning for projects... [INFO] --------------------------------- [INFO] Building LeaguePlanet.com Web Project [INFO] task-segment: [test] [INFO] --------------------------------- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] While downloading servletapi:servletapi:2.3 This artifact has been relocated to javax.servlet:servlet-api:2.3. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Setting reports dir: C:\workspace\LeaguePlanetWebProject\target/surefire-reports ------------------------------------------------------------- T E S T S ------------------------------------------------------------- [surefire] Running com.leagueplanet.tests.LeaguePlanetBVTTest [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [INFO] ------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------ [INFO] Total time: 2 seconds [INFO] Finished at: Sat May 13 15:58:43 EEST 2006 [INFO] Final Memory: 3M/6M [INFO] ------------------------------------------------------
You will find the Maven JUnit test reports under the target/surefire-reports folder. Of course, XML reports can be transformed into a more human-readable format, but you will see in the next section that Maven also does this for you (see Figure 6.49).
)
Figure 6.49 Maven JUnit Test Reports
Project Information and Reports
The Maven project model can also contain information about the developers, configuration and version control systems, issue tracking, mailing lists, and other process-related project information. This information is used by Maven plug-ins to generate project information and reports. The listing shown in Example 6.13 provides the complete code for a typical Maven project model.
Example 6.13. Listing of pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>leagueplanet</artifactId>
<groupId>com.leagueplanet</groupId>
<name>LeaguePlanet.com Web Project</name>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<organization>
<name>LeaguePlanet.com</name>
<url>http://www.leagueplanet.com/</url>
</organization>
<description>
An example project showing how to use eclipse WebTools Platform
and Maven for Java Web Development.
</description>
<licenses>
<license>
<comments>Eclipse Public Licence (EPL)v1.0</comments>
<url>http://www.eclipse.org/legal/epl-v10.html</url>
</license>
</licenses>
<developers>
<developer>
<id>ndai</id>
<name>Naci Dai</name>
<email>naci.dai@eteration.com</email>
<organization>Eteration</organization>
</developer>
<developer>
<id>lmandel</id>
<name>Lawrence Mandel</name>
<email>lmandel@ca.ibm.com</email>
<organization>IBM</organization>
</developer>
<developer>
<id>ryman</id>
<name>Arthur Ryman</name>
<email>ryman@ca.ibm.com</email>
<organization>IBM</organization>
</developer>
</developers>
<build>
<finalName>${artifactId}-${version}</finalName>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>struts</groupId>
<artifactId>struts</artifactId>
<version>1.2.7</version>
</dependency>
<dependency>
<groupId>struts</groupId>
<artifactId>struts-el</artifactId>
<version>1.2.7</version>
</dependency>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.1.4</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.3</version>
</dependency>
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<version>2.7.5</version>
</dependency>
<dependency>
<groupId>commons-digester</groupId>
<artifactId>commons-digester</artifactId>
<version>1.7</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.7.0</version>
</dependency>
<dependency>
<groupId>oro</groupId>
<artifactId>oro</artifactId>
<version>2.0.8</version>
</dependency>
<dependency>
<groupId>servletapi</groupId>
<artifactId>servletapi</artifactId>
<version>2.3</version>
</dependency>
</dependencies>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>
maven-project-info-reports-plugin
</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
</plugin>
</plugins>
</reporting>
</project>
The project reports are generated using the Maven site goal. This goal builds a local copy of the project site for reports, documentation, and reference. The result is generated into the target/site directory in the project's base directory, which contains an entire Web site of documentation (see Figure 6.50).
)
Figure 6.50 Maven Project Reports