Building Web Applications with Maven 二[转自官网]

Building Web Applications with Maven 2[转自官网]

官网：http://today.java.net/pub/a/today/2007/03/01/building-web-applications-with-maven-2.html

?

You may have heard of Maven 2--it's often touted by
technologists as a replacement for Ant. You may have even taken
some time to browse around on the Maven 2 site, but
maybe the documentation has left you a little bit unclear on where and
how to go about getting started.

In this article, we will take a look at using Maven 2 to help
build a simple web application (a bit of business logic in a JAR
and a JSP-based web application). By the end of this article, you
should feel comfortable working with Maven 2, and ready to start
using it as a much more satisfactory tool than Ant (or even your
IDE).

These instructions assume that you have installed Java 5 and Maven
2. The following two commands shown should work at your command
line:

To create a simple Java project, you simply execute the command
as shown.

Figure 1. Source for JAR project layout
Clicking through the results, you will see folders and two Java
source files--so far, nothing surprising.
In the root folder, however, we notice a file called pom.xml.

Figure 2. Maven 2 project file for JAR project
This file is essentially analogous to an IDE project file: it
contains all of the information about a project, and is the file
that Maven 2 uses to act upon to execute commands. The contents of
pom.xml:
command is a lifecycle command. A lifecycle command is a
series of plugin commands strung together. For example, the test
lifecycle command might include several plugin commands in a
series.
Let's execute the lifecycle command 
Figure 3. WAR project directory structure
Simply executing the command 
Figure 4. Resulting WAR file
Now that we have a WAR file, we would like to be able to run the
application. To do this, we simply add the Jetty plugin to the
pom.xml for this web application as shown:

Figure 5. Hello World Web Application
Tying Together the Logic and Web Application
Now, we simply have to tie together the logic in our JAR file
and the web application. First, we want to set up a dependency
between our JAR and the web application. This will tell Maven 2
that we want to use this JAR file in our WAR, which will cause
Maven 2 to automatically copy the JAR file when we package our WAR
file.
First, we add the dependency on this other JAR file to our
pom.xml for the web application as shown below.

Figure 6. Verifying the JAR copied into the WAR
When we execute the 
Figure 7. WAR running with business logic from JAR
To recap, we now have two independent projects running on our
system. When we run 

Figure 8. Location of master project file
Now, we can simply execute a single command, but in brief, Maven 2 makes use of two kinds of repository: local
and remote. These repositories serve as locations for Maven 2 to
automatically pull dependencies. For example, our pom.xml
file above makes use the local repository for managing the
dependency on the JAR file, and the default Maven 2 remote
repository for managing the dependencies on JUnit and Jetty.
Generally speaking, dependencies come from either the local
repository or remote repositories. The local repository is used by
Maven 2 to store downloaded artifacts from other repositories. The
default location is based on your system. Figure 9 shows the local
repository on my laptop as of the writing of this article.

Figure 9. Local repository example
If Maven 2 can't resolve a dependency in the local repository,
it will try to resolve the dependency using a remote
repository.
The default remote repository, known as Ibiblio, includes many of the most popular open source packages. You can browse the wide range of packages on Ibiblio with the URL above and add dependencies as needed. For example, let's say that you would like to use Hibernate in your project. Navigating to www.ibiblio.org/maven/org.hibernate/poms,
we can see there are a wide number of releases of Hibernate
available. Opening up a sample Hibernate pom file, we can see that we
simply need to add the appropriate groupId,
artifactId, and version entries to our
business logic pom.xml file (the scope flag tells Maven 2 which
lifecycle is interested in the dependency).
<dependency>??????? <groupId>org.hibernate</groupId>??????? <artifactId>hibernate</artifactId>??????? <version>3.2.1.ga</version>??????? <scope>compile</scope> </dependency>
Simply adding this dependency to the pom.xml file will
cause Maven 2 to automatically download Hibernate and make the
appropriate JAR files available to both the business logic JAR file
and the WAR file.
You can set up your own remote repository, and add an entry to
the pom.xml file to look in that repository for artifacts.
This is extremely useful for enterprises that make use of shared
resources (for example, one group may wish to publish JAR files
that are used to access a particular piece of middleware).
Finally, you may instead wish to install your own JARs into the
local repository. For example, if you have a
Simple.jar file that someone gave you, use the command
shown below (choosing groupId and
artifactId values that are highly likely to be unique
to avoid a namespace collision).
mvn install:install-file???? -Dfile=Sample.jar???? -DgroupId=uniquesample???? -DartifactId=sample_jar???? -Dversion=2.1.3b2???? -Dpackaging=jar???? -DgeneratePom=true
Summary
In this article, we looked at how a few commands and some tiny
XML files allow us to create, compile, test, bundle, and manage
project dependencies. We built a simple web application and
deployed it to a web server with just a few commands, and we still
haven't touched on many of the features of Maven 2. For example,
additional commands generate integrated Javadocs across multiple
projects, code coverage reports, or even a complete website with
documentation. With luck, this orientation to Maven 2 has given you
enough information to begin the transition. Eventually, tools such
as Eclipse and NetBeans will almost certainly support Maven 2 (or
something like it) natively. In the meantime, you can dramatically
reduce your use of raw Ant (and spend a lot less time fighting XML
build scripts) by switching even small projects over to Maven
2.