Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Maven is a popular open source build tool for enterprise Java projects, designed to take much of the hard work out of the build process. Maven uses a declarative approach, where the project structure and contents are described, rather then the task-based approach used in Ant or in traditional make files, for example. This helps enforce company-wide development standards and reduces the time needed to write and maintain build scripts.
The declarative, lifecycle-based approach used by Maven 1 is, for many, a radical departure from more traditional build techniques, and Maven 2 goes even further in this regard. In this article, I go through some of the basic principals behind Maven 2 and then step through a working example. Let's start by reviewing the fundamentals of Maven 2.
The heart of a Maven 2 project is the project object model (or POM for short). It contains a detailed description of your project, including information about versioning and configuration management, dependencies, application and testing resources, team members and structure, and much more. The POM takes the form of an XML file (pom.xml), which is placed in your project home directory. A simple pom.xml file is shown here:
<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> <groupId>com.javaworld.hotels</groupId> <artifactId>HotelDatabase</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>Maven Quick Start Archetype</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
Much of Maven's power comes from the standard practices it encourages. A developer who has previously worked on a Maven project will immediately feel familiar with the structure and organization of a new one. Time need not be wasted reinventing directory structures, conventions, and customized Ant build scripts for each project. Although you can override any particular directory location for your own specific ends, you really should respect the standard Maven 2 directory structure as much as possible, for several reasons:
The standard Maven 2 directory structure is illustrated in Figure 1. In the project home directory goes the POM (pom.xml) and two subdirectories: src for all source code and target for generated artifacts.
Figure 1. The standard Maven 2 directory layout
The src directory has a number of subdirectories, each of which has a clearly defined purpose:
Project lifecycles are central to Maven 2. Most developers are familiar with the notion of build phases such as compile, test,
and deploy. Ant has targets with names like those. In Maven 1, corresponding plug-ins are called directly. To compile Java
source code, for instance, the
java plug-in is used:
In Maven 2, this notion is standardized into a set of well-known and well-defined lifecycle phases (see Figure 2). Instead
of invoking plug-ins, the Maven 2 developer invokes a lifecycle phase:
Figure 2. Maven 2 lifecycle phases
Some of the more useful Maven 2 lifecycle phases are the following:
generate-sources: Generates any extra source code needed for the application, which is generally accomplished using the appropriate plug-ins
compile: Compiles the project source code
test-compile: Compiles the project unit tests
test: Runs the unit tests (typically using JUnit) in the src/test directory
package: Packages the compiled code in its distributable format (JAR, WAR, etc.)
integration-test: Processes and deploys the package if necessary into an environment where integration tests can be run
install: Installs the package into the local repository for use as a dependency in other projects on your local machine
deploy: Done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects
Many other lifecycle phases are available. See Resources for more details.
These phases illustrate the benefits of the recommended practices encouraged by Maven 2: once a developer is familiar with the main Maven 2 lifecycle phases, he should feel at ease with the lifecycle phases of any Maven project.
The lifecycle phase invokes the plug-ins it needs to do the job. Invoking a lifecycle phase automatically invokes any previous lifecycle phases as well. Since the lifecycle phases are limited in number, easy to understand, and well organized, becoming familiar with the lifecycle of a new Maven 2 project is easy.
One of the highlights of Maven 2 is transitive dependency management. If you have ever used a tool like urpmi on a Linux box, you'll know what transitive dependencies are. With Maven 1, you have to declare each and every JAR that will be needed, directly or indirectly, by your application. For example, can you list the JARs needed by a Hibernate application? With Maven 2, you don't have to. You just tell Maven which libraries you need, and Maven will take care of the libraries that your libraries need (and so on).
Suppose you want to use Hibernate in your project. You would simply add a new dependency to the
dependencies section in pom.xml, as follows:
<dependency> <groupId>hibernate</groupId> <artifactId>hibernate</artifactId> <version>3.0.3</version> <scope>compile</scope> </dependency>
And that's it! You don't have to hunt around to know in which other JARs (and in which versions) you need to run Hibernate 3.0.3; Maven will do it for you!
The XML structure for dependencies in Maven 2 is similar to the one used in Maven 1. The main difference is the
scope tag, which is explained in the following section.
In a real-world enterprise application, you may not need to include all the dependencies in the deployed application. Some JARs are needed only for unit testing, while others will be provided at runtime by the application server. Using a technique called dependency scoping, Maven 2 lets you use certain JARs only when you really need them and excludes them from the classpath when you don't.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Maven2 is not a silver bullet By Ganja|
|Maven2 For Desktop Applications Instead of Web App By Anonymous|
|flawed JSP code By Odi|
|An introduction to Maven 2 By JavaWorld|