1 关键名词
Project：任何您想build的事物，Maven都可以认为它们是工程。这些工程被定义为工程对象模型(POM，Poject Object Model)。一个工程可以依赖其它的工程；一个工程也可以由多个子工程构成。
POM：POM(pom.xml)是Maven的核心文件，它是指示Maven如何工作的元数据文件，类似于Ant中的build.xml文件。POM文件位于每个工程的根目录中。
GroupId：groupId是一个工程的在全局中唯一的标识符，一般地，它就是工程名。groupId有利于使用一个完全的包名，将一个工程从其它有类似名称的工程里区别出来。
Artifact：artifact 是工程将要产生或需要使用的文件，它可以是jar文件，源文件，二进制文件，war文件，甚至是pom文件。每个artifact都由groupId和 artifactId组合的标识符唯一识别。需要被使用(依赖)的artifact都要放在仓库(见Repository)中，否则Maven无法找到 (识别)它们。
Dependency：为了能够build或运行，一个典型的Java工程会依赖其它的包。在Maven中，这些被依赖的包就被称为dependency。dependency一般是其它工程的artifact。
Plug-in：Maven是由插件组织的，它的每一个功能都是由插件提供的。插件提供goal(类似于Ant中的target)，并根据在POM中找到的元数据去完成工作。主要的Maven插件要是由Java写成的，但它也支持用Beanshell或Ant脚本写成的插件。
Repository：仓库用于存放artifact，它可以是本地仓库，也可以是远程仓库。Maven有一个默认的远程仓库--central，可以从http://www.ibiblio.org/maven/下载其中的artifact。在Windows平台上，本地仓库的默认地址是User_Home\.m2\repository。
Snapshot：工程中可以(也应该)有一个特殊版本，它的版本号包括SNAPSHOT字样。该版本可以告诉Maven，该工程正处于开发阶段，会经常更新(但还未发布)。当其它工程使用此类型版本的artifact时，Maven会在仓库中寻找该artifact的最新版本，并自动下载、使用该最新版。
2 Maven Build Life Cycle
软件项目一般都有相似的开发过程：准备，编译，测试，打包和部署，Maven将上述过程称为Build Life Cycle。在Maven中，这些生命周期由一系列的短语组成，每个短语对应着一个(或多个)操作；或对应着一个(或多个)goal(类似于Ant中的 target)。
如编译源文件的命令mvn compile中的compile是一个生命周期短语。同时该命令也可以等价于mvn compiler:compile，其中的compiler是一个插件，它提供了compile(此compile与mvn compile中的compile意义不同)goal；compiler还可提供另一个goal--testCompile，该goal用于编译junit测试类。
在执行某一个生命周期时，Maven会首先执行该生命周期之前的其它周期。如要执行compile，那么将首先执行validate，generate- source，process-source和generate-resources，最后再执行compile本身。关于Maven中默认的生命周期短语，请见参考资源[6]中的附录B.3。
3 标准目录布局
Maven为工程中的源文件，资源文件，配置文件，生成的输出和文档都制定了一个标准的目录结构。Maven鼓励使用标准目录布局，这样就不需要进行额外 的配置，而且有助于各个不同工程之间的联接。当然，Maven也允许定制个性的目录布局，这就需要进行更多的配置。关于Maven的标准目录布局，请见参考资源[6]中的附录B.1。
4 Maven的优点
[1]build逻辑可以被重用。在Ant中可能需要多次重复地写相同的语句，但由于POM的继承性，可以复用其它的POM文件中的语句。这样既可以写出清晰的build语句，又可以构造出层次关系良好的build工程。
[2]不必关注build工作的实现细节。我们只需要使用一些build生命周期短语就可以达到我们的目标，而不必管Maven是如何做到这些的。如，只需要告诉Maven要安装(install)，那么它自然就会验证，编译，打包，及安装。
[3]Maven会递归加载工程依赖的artifact所依赖的其它artifact，而不用显示的将这些artifact全部写到dependency中。
[4]如果完全使用Maven的标准目录布局，那么可以极大地减少配置细节。
5 实例
5.1 构想
由于只是阐述Maven的基本使用方法，所以本文将要设计的实例，只是一个简单的Maven demo。该实例包含两个工程：普通应用程序工程(app)和Web应用工程(webapp)。app工程提供一个简单的Java类；webapp工程只 包含一个Servlet，并将使用app中的Java类。
该Demo的目标是能够正确地将webapp制成war包，以供部署时使用。要能够正确制作war，自然首先就必须要能够正确的编译源代码，且要将App模块制成jar包。本文创建的工程所在的目录是D:\maven\demo。
5.2 App工程
可以使用Maven的archetype插件来创建新工程，命令如下：
D:\maven\demo>mvn archetype:create -DgroupId=ce.demo.mvn -DartifactId=app
该工程的groupId是ce.demo.mvn，那么该工程的源文件将放在Java包ce.demo.mvn中。artifactId是app，那么该工程根目录的名称将为app。
当第一次执行该命令时，Maven会从central仓库中下载一些文件。这些文件包含插件archetype，以及它所依赖的其它包。该命令执行完毕后，在目录D:\maven\demo下会出现如下目录布局：
app
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- ce
| `-- demo
| `-- mvn
| `-- App.java
`-- test
`-- java
`-- ce
`-- demo
`-- mvn
`-- AppTest.java
因本文暂时不涉及JUnit测试，故请将目录app\src\test目录删除。然后再修改App.java文件，其完全内容如下：
package ce.demo.mvn;
public class App {
public String getStr(String str) {
return str;
}
}
其实，如果我们能够清楚地知道Maven的标准目录布局，就可以不使用archetype插件来创建工程原型；如果我们要定制个性的目录布局，那么就更没有必要使用archetype插件了。
5.3 WebApp工程
我们仍然如创建app工程一样使用archetype插件来创建webapp工程，命令如下：
D:\maven\demo>mvn archetype:create -DgroupId=ce.demo.mvn -DartifactId=webapp -DarchetypeArtifactId=maven-archetype-webapp
第一次运行此命令时，也会从central仓库中下载一些与Web应用相关的artifact(如javax.servlet)。此命令与创建app的命 令的不同之处是，多设置了一个属性archetypeArtifacttId，该属性的值为maven-archetype-webapp。即告诉 Maven，将要创建的工程是一个Web应用工程。创建app工程时没有使用该属性值，是由于archetype默认创建的是应用程序工程。同样的，执行 完该命令之后，会出现如下标准目录布局：
webapp
|-- pom.xml
`-- src
`-- main
`-- webapp
|-- index.jsp
|-- WEB-INF
`-- web.xml
根据5.1节的构想，webapp工程将只包含一个Servlet，所以我们不需要index.jsp文件，请将其删除。此时大家可以发现，目前的目录布 局中并没有放Servlet，即Java源文件的地方。根据参考资源[6]中的附录B.1，以及app工程中Java源文件的布局，可以知道 Servlet（它仍然是一个Java类文件）仍然是放在webapp\src\main\java目录中，请新建该目录。此处的Servlet是一个简单HelloServlet，其完整代码如下：
package hello;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import ce.demo.mvn.App; // 引用app工程中的App类
public class HelloServlet extends HttpServlet {
private static final long serialVersionUID = -3696470690560528247L;
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
App app = new App();
String str = app.getStr("CE Maven Demo");
PrintWriter out = response.getWriter();
out.print("<html><body>");
out.print("<h1>" + str);
out.print("</body></html>");
}
}
5.4 POM文件
大家可以发现，在前面新建工程时，我们并没有提到各个工程中的pom.xml文件。现在将要讨论这个问题。我们先看看app工程中的POM文件，其完整内容如下：
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>ce.demo.mvn</groupId>
<artifactId>app</artifactId>
<packaging>jar</packaging>
<version>1.0</version>
<name>CE Maven Demo -- App</name>
</project>
大家可以发现此我帖出来的内容与实际由archetype插件生成的POM文件的内容有些不同，但基本上是一致的。只是为了使文件中的语句更清晰，此处删 除了一些冗余的内容，并修改了该工程的version和name的值，以与此例子的背景来符合。在目前情况下modelVersion值将被固定为 4.0.0，这也是Maven2唯一能够识别的model版本。groupId，artifactId的值与创建工程时使用的命令中的相关属性值是一致 的。packaging的值由工程的类型决定，如应用程序工程的packaging值为jar，Web应用工程的packaging值为war。上述情况 也可以从webapp的POM文件中看出，下面将看看这个pom的完整内容。
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>ce.demo.mvn</groupId>
<artifactId>webapp</artifactId>
<packaging>war</packaging>
<version>1.0</version>
<name>CE Maven Demo -- WebApp</name>
<dependencies>
<dependency>
<groupId>ce.demo.mvn</groupId>
<artifactId>app</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
比较app与webapp中的POM，除前面已经提过的packaging的差别外，我们还可以发现webapp中的POM多了dependencies 项。由于webapp需要用到app工程中的类(见HelloServlet源代码)，它还需要javax.servlet包(因为该包并不默认存在于 jsdk中)。故，我们必须要将它们声明到依赖关系中。
5.5 执行
上述两个工程创建完毕后，就需要执行一些命令来看看会有什么结果出现。我们首先进入app目录，并执行命令mvn compile，然后会在该目录下发现新生成的目录target\classes，即编译后的class文件(包括它的包目录)就放在了这里。再执行命令mvn package，在目录target中就会生成app-1.0.jar文件。该文件的全名由如下形式确定：artifactId-version.packaging。根据第2章的叙述可以知道，执行命令mvn package时，将首先将产生执行命令mvn compile之后的结果，故如果要打包，那么只需要执行mvn package即可。
在app工程中执行完之后，就需要进入webapp工程了。进入webapp目录，此次将只执行mvn package命令(隐示地跳过了compile过程)。此次命令的执行并不成功，会出现如下问题：
D:\maven\demo\webapp>mvn package
……
Downloading: http://repo1.maven.org/maven2/ce/demo/mvn/app/1.0/app-1.0.pom
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: ce.demo.mvn:app
Reason: Error getting POM for 'ce.demo.mvn:app' from the repository: Error transferring file
ce.demo.mvn:app:pom:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
……
由加粗的内容可知，Maven正试图从central仓库下载app工程的artifact，但central仓库肯定不会有这个artifact，其结 果只能是执行失败!由第1章artifact名词的解释可知，被依赖的artifact必须存在于仓库(远程或本地)中，但目前webapp所依赖的 app必不存在于仓库中，所以执行只能失败。
解决这个问题有两种方法：[1]将app-1.0.jar安装到仓库中，使它成为一个artifact；[2]构建一个更高层次的工程，使app和webapp成为这个工程的子工程，然后从这个更高层次工程中执行命令。
第一种方法比较简单（见http://www.blogjava.net/jiangshachina/admin/EditPosts.aspx中的第一个主题），此处将详细讨论第2种方法(见5.6节)。
5.6 更高层次工程
我们可以将app和webapp的上一级目录demo作为这两个工程的更高层次一个工程。为了使demo目录成为一个demo工程，只需要在这个目录下添加一个pom.xml文件，该文件内容如下：
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>ce.demo</groupId>
<artifactId>mvn-demo</artifactId>
<packaging>pom</packaging>
<version>1.0</version>
<name>CE Maven Demo</name>
<modules>
<module>app</module>
<module>webapp</module>
</modules>
</project>
与app和webapp中的POM相比，demo的POM使用了modules项，modules用于声明本工程的子工程，module中的值对应于子工程的artifact名。而且该POM的packaging类型为pom。
有了demo工程后，我们只需要在demo目录下执行相关命令就可以了。通过如下命令即可验证：
[1]mvn clean – 消除工程(包括所有子工程)中产生的所有输出。这本文的实例中，实际上是删除target目录。由于之前的操作只有app工程产生了target目录，而webapp并没有，所以将只会删除app工程中的target目录。
[2]mvn package – 将工程制作成相应的包，app工程是作成jar包(app-1.0.jar)，webapp工程是作成war包(webapp-1.0.war)。打开webapp-1.0.war包，可以发现app-1.0.jar被放到了WEB-INF的lib目录中。
6 小结
通过以上的叙述与实例，应该可以对Maven有一个粗略的认识了。使用Maven关键是要弄清楚如何写pom.xml文件，就如同使用Ant要会写 build.xml文件一样。在POM中可以写入Ant的task脚本，也可以直接调用Ant的build.xml文件(推荐)，所以Maven也可以完 成Ant的绝大多数工作(但不必安装Ant)。
利用好Maven的继承特性及子工程的关系，可以很好地简化POM文件，并构建层次结构良好的工程，有利于工程的维护。
7 参考资源
[1]Maven官方网站. http://maven.apache.org
[2]Maven POM文件参考结构. http://maven.apache.org/ref/current/maven-model/maven.html
[3]Super POM. http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
[4]Maven主要插件的列表. http://maven.apache.org/plugins
[5]Maven基本使用指南. http://maven.apache.org/guides/index.html
[6]Better Build with Maven. http://www.mergere.com/m2book_download.jsp -- 强烈推荐
[7]介绍Maven2. http://www.javaworld.com/javaworld/jw-12-2005 /jw-1205-maven_p.html
[8]揭秘Maven2 POM. http://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html
[9]Maven让事情变得简单. http://www-128.ibm.com/developerworks/cn/java/j-maven
[10]Maven文档集. http://docs.codehaus.org/display/MAVENUSER/Home
[11]有效利用Maven2的站点生成功能. http://www.matrix.org.cn/resource/article/44/44491_Maven2.html
文中例子程序下载：http://www.blogjava.net/files/jiangshachina/maven.rar
-------------------------------end---------------------
|
1. 什么是maven
3. maven的依赖管理 maven对项目依赖的库文件进行集中管理，所有库文件都以一定结构存放在repository中，并用artifactId,groupId, version三个属性来标示它们。当项目需要某些库文件时，只要指明这三个属性即可。库文件在repository中存储结构也和这三个属性紧密相关，其关系为${mave.repo.remote}//s/ -.。也就是假定repository的根目录为/javarepository那么 groupId为spring，artifactId为spring-orm，版本(version)为1.1.3的jar的库文件的存储路径为 /javarepository/spring/jars/spring-orm-1.1.3.jar。 maven的repository通常放在对公众开放的主机上，并由众多的镜像构成，最主要的是http://www.ibiblio.org/maven/。选择哪些repository是通过 Java系统变量maven.repo.remote。比如下面的配置maven.repo.remote=http://ultra/maven/, http://www.ibiblio.org/maven/,http://boss.bekk.no/maven/,http://mirrors.sunsite.dk/maven, http://www.ganet.org/maven将使maven从www.ibiblio.org,boss.bekk.no, mirrors.sunsite.dk,www.ganet.org四个站点依次寻找依赖的文件。该变量可以在四个地方设置:
3. maven的主要功能 maven是个构建工具的集成平台，所有功能都是通过插件实现的。maven内置和第三方扩展工具提供了大量功能，除了包括基本的编译、打包、java文档生成、运行单元测试外，还有j2ee项目支持，代码生成，产生测试覆盖率报告，项目开发过程各种文档的发布。 4. 使用maven的案例分析 背景，轻量级J2EE项目，dhtml+struts+spring+hibernate+dbunit，使用ER模型进行数据库设计 工具需求:
5. maven的经验总结
摘要:Maven1.0已经历了几年的时间，并且作为Ant的替代品已被广大的开发人员所接收，但它并没有在很大程度使开发人员从Ant的build.xml文件中解脱出来。Maven1.0速度慢并且笨拙，使用起来的困难度并不亚于使用Ant的项目。事实上，它的核心是基于Ant实现的。在经过了几乎彻底的重写后，Maven2.0诞生了。
一个Java项目中最困难的地方就是如何着手启动它。在启动项目之前，我们必须配置好所有的逻辑关系。比如，Java源代码应该放在何处？单元测试应该在何处进行？依赖的jar包应该如何放置？如何构建项目，如何形成文档，如何测试和部署项目？在这种情况下，开发人员不同的处理选择将会影响项目的余下部分。您的选择可能会使你陷入困境，也可能会在将来证明您是一位Java架构大师。我们假定后者是我们奋斗的目标，接下来就进入我们的正题。
构建一个Java项目可以使用很多工具，其中包括Ant。Ant作为一款具有革命性的工具，一直是众多开发者使用工具中的首选，它能使开发人员摆脱使用大量make命令的苦海。对于那些不太熟悉make命令的人来说，他们有充足的理由来表明使用命令并不是构建Java项目的最好工具，因为它不具备平台独立性并且不易使用。Ant的出现解决了以上的问题，它使用了一个平台独立的工具，该工具能够解析XML配置文件，即build.xml。虽然Ant由于其诸多的优点而备受欢迎，但它同样有一些缺点。build.xml文件由于采用了极其简短的描述方式，使得开发人员需要预先学习它的语法。虽然学习曲线不是很陡峭，但Java开发人员更应该把时间放在开发上面。 Maven是新一代的生力军，它的境遇正好和几年前的Ant十分类似。Maven1.0已经历了几年的时间，并且作为Ant的替代品已被广大的开发人员所接收，但它并没有在很大程度使开发人员从Ant的build.xml文件中解脱出来。Maven1.0速度慢并且笨拙，使用起来的困难度并不亚于使用Ant的项目。事实上，它的核心是基于Ant实现的。在经过了几乎彻底的重写后，Maven2.0诞生了。 Maven2.0的优点 Maven2.0有许多很好功能，这些功能不仅仅是帮助您构建项目。如果您刚刚开始启动一个Java项目，并且想使该项目快速地开展下去，Maven2.0能够在几分钟内达到您的要求。以下是Maven2.0的一些优点： --标准的项目布局和项目结构生成器 --标准的依赖管理机制 --多项目支持 --在开发者需要的时候及时地下载新的插件和功能部件 --生成最新项目信息的网站 --集成了源代码控制软件：CVS和Subversion 以上列表展示的只是Maven2.0特点中的一小部分。但这足以使Maven2.0成为一个构建管理系统可靠的选择。既然我们已经知道Maven是个什么东西了，接下来让我们看看如何使用它。 入门 我们要做的第一件事情就是设置目录结构，但这并不需要让我们手动设置，Maven会根据您开发的项目类型来为您做这件事。一旦您下载并解压了最新发布的Maven 2.0，您应该将Maven所在目录下面的bin目录添加到您的系统路径下。您可以运行命令mvn -version来测试您的安装。 既然已经安装上了工具，让我们看看创建一个简单的Java项目的例子。Maven使用原型来决定目录结构是如何展现的。Maven自带了几个内建的原型，您也可以自定义原型。 mvn archetype:create -DgroupId=com.oreilly -DartifactId=my-app 您看，这就生成了我们的项目布局。 my-app ----src ----main ----java ----com ----oreilly ----test ----java ----com ----oreilly 对，就这么简单。这种目录结构可以通过创建一个新的原型来覆写，但并不推荐这么做，因为Maven的一个优点就是使用标准的目录结构。该目录结构包含两个源代码树，一个是Java应用程序的源代码，另一个是单元测试代码。同时您也许会注意到，当第一次运行Maven的时候，它会进行一些下载工作。当您开始调用工具时，Maven会根据您使用的插件来更新自身的一些所需功能。Maven默认会从Ibiblio存储库中得到更新。您可以在Maven安装目录下的conf目录中，或者项目自身中修改Maven远程存储库的选择。 您会发现Maven在my-app目录下创建了一个pom.xml文件。这是项目的最基本部分。pom.xml文件包含了一组指令，这些指令告诉Maven如何构建项目和包含哪些其它的特殊指令（POM是“项目对象模型”的缩写）。在默认的情况下，Maven包含了JUnit的依赖以此来鼓励单元测试。 <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.oreilly</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</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>
创建完项目后，我们可以往项目里添加代码并使用Maven的所有全新技巧。注意以下命令必须在pom.xml文件所在的目录中运行。 --mvn test：运行应用程序中的单元测试 --mvn package：依据项目生成jar文件 --mvn install：将项目的jar文件添加到库中， 以备依赖此项目时使用 --mvn site：生成项目相关信息的网站 --mvn clean：清除目标目录中的生成结果 --mvn eclipse:eclipse：生成Eclipse项目文件 接下来我们看看稍微复杂点的地方，我们知道手动开始一个Java web项目比手动开始一个简单的Java项目更耗时，然而Maven的使用则能化难为易。下面的例子（实际上是一行命令）展现了项目结构的构造。 mvn archetype:create -DgroupId=com.oreilly -DartifactId=Oreilly -DarchetypeArtifactId=maven-archetype-webapp 生成的结果结构如下所示： Oreilly ----src ----main ----resources ----webapp ----WEB-INF 这一次，我们的项目由于支持了将包含在war文件中的web资源而设置有所不同。pom.xml文件中将包含一行来表明项目应该被打包成war文件：<packaging>war</packaging>。现在就可以使用mvn package命令来生成war文件。不用担心如何从WEB-INF/lib目录中得到依赖项，在依赖属性值被设置成compile的情况下，Maven会自动包含依赖项。也可以将以下代码添加到pom.xml文件中来改变war文件的名称： <build>
<finalName>PromoteC</finalName>
</build>
依赖管理 创建好项目结构，添加完一些代码，测试并编译好应用程序后，接下来可以看看Maven是如何处理依赖关系的。为了给项目添加一个依赖项，必须将此依赖项添加到pom.xml文件中。下次运行Maven的时候，它将从Ibiblio存储库中得到这个依赖项，并且将此依赖项添加到项目构建路径中。 关于依赖的问题有几个重要的事情值得注意。在写这篇文章的时候，Maven中最大的麻烦之处就是不能从Maven存储库中获取Sun的jar文件。这个问题归因于Sun在其代码中设置的许可证限制。解决这个问题的办法有两种，一种是下载这些代码并将它们安装在您本地的存储库中，另一种是做一个外部声明，并将这个声明指向文件系统中依赖项所在的位置。希望Sun能够尽早地创建自己的存储库，尽管如此，Maven也会被升级来使之能够下载这些资源，只是在下载之前它会提示用户接受许可证协议。 另外一个麻烦的地方就是有时候使用的最新的库文件可能在远程存储库中不存在。另一种可能是由于无法访问Internet，需要所有的依赖项都能在本地获取。这些问题的最好解决方案就是将jar文件安装到本地的存储库中。将本地的存储库放在一台web服务器上也同样是个便利之举，这样整个开发团队就能从此获益，每个人都没有必要去管理自己的存储库了。改变Maven的存储库路径只需简单地编辑其安装目录下conf文件夹下面的settings.xml文件即可。 在Maven中使用依赖是简单的。让我们看看往上述pom.xml文件中添加一个依赖项的情况。我们虽然已经使用了JUnit，但让我们将功能强大的Quartz库添加到项目中。Quartz是一款用纯Java编写的关于时间安排的开源项目，它是您时间安排需求方面的很好的选择。 <dependency>
<groupId>quartz</groupId>
<artifactId>quartz</artifactId>
<version>1.5.1</version>
<scope>compile</scope>
</dependency>
我们仅仅只需添加<dependencies>这个元素，Maven就能下载Quartz并将其作为项目中的一个依赖项。不用担心Quartz的依赖项，一个Maven的存储库将包含依赖项自身依赖的资源信息，当Maven下载Quartz的时候，它自身的依赖资源也同样会被下载。为了验证版本为1.5.1的Quartz存在于Ibiblio库中，我们可以浏览Maven存储库。注意到scope参数的使用，它告诉了Maven依赖项在何种阶段是所需的。在使用JUnit的情况下，我们设置scope参数的值为test来告诉Maven这个依赖项只是在测试阶段所需的，而不是运行时所需的资源。以下是scope参数值的说明： --compile：默认值。表明是所有任务所需的资源 --test：运行所有的测试用例时所需资源 --runtime：表明是运行时所需资源 --provided：JDK部分或应用服务器的classpath所需的资源 现在，如何处理那些麻烦的Sun的jar包和那些需要但却不能在远程存储库中找到的jar包了？我们必须使用Maven来手动将这些jar包安装到本地的存储库中。不用担心，这没有听上去那么困难。为了做个示例，我们将安装Java Activation框架的jar包。首先我们必须从Sun的站点上下载此jar包，接着我们使用Maven将它导入本地的存储库中。您自己也可以按照Maven上传资源指南中的指导将缺少的jar包安装到Ibiblio中。 mvn install:install-file -Dfile=activation.jar -DgroupId=javax.activation -DartifactId=activation -Dversion=1.0 -Dpackaging=jar 现在，新的jar包就像其它的项目依赖项一样安装到了本地存储库中。在只需添加依赖声明后，我们就已准备就绪了。在添加jar包和声明它们为依赖项时，必须确保版本信息的正确性。版本的不匹配会导致Maven在寻找资源时的失败。在导入Sun的jar包时，如果您需要寻求标准命名参数的帮助，可以参考Sun标准jar包命名。记住，在目前您不能通过存储库来公开发布这些jar包，这将违反Sun的使用条款。 <dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
您或许想将依赖项存入一个源代码控制器的库中，源代码控制器决不能执行这个任务。依赖项是经常变化的，并且通常有一套数字方案来标明其版本。这就是说，您明确地希望有一个内部远程存储库的备份，如果您有一个，这将确保在存储库服务器崩溃并且不能恢复的情况下，您不会丢失所有的自定义资源。不将依赖项放入源代码控制器中也会节省源代码控制器的存储库服务器上的大量磁盘空间。 配置存储库 要求项目的每个开发者必须在conf目录中配置存储库是不方便的，所以Maven可以同时查看多个存储库并且将它们全部配置在pom.xml文件中。让我们看看一个例子，它展示了如何在应用程序用使用多个存储库。在以下从pom.xml文件摘录的片断中，我们设置了两个存储库来让Maven寻找依赖项。Ibiblio一直是默认的存储库，我们又添加了Planet Mirror作为后援存储库。我们也可以让团队使用的本地web服务器作为第二个存储库。 <repositories>
<repository>
<id>Ibiblio</id>
<name>Ibiblio</name>
<url>http://www.ibiblio.org/maven/</url>
</repository>
<repository>
<id>PlanetMirror</id>
<name>Planet Mirror</name>
<url>http://public.planetmirror.com/pub/maven/</url>
</repository>
</repositories>
使用pom.xml父文件来构建多个项目 软件公司通常的一种做法就是将多个项目构建到主要产品中。维护依赖关系链和一次性地构建整个产品足以成为一个挑战，但是如果使用Maven的话，事情将变得简单。如果您创建了一个指向其它子模块的pom.xml父文件，Maven将为您处理整个构建过程。它将分析每个子模块的pom.xml文件，并且按照这些子模块的相互依赖顺序来构建项目。如果每个项目明确地指明它们的依赖项，那么子模块在父文件中的放置顺序是不造成任何影响的。但是考虑到其他的开发者，最好保证子模块在pom.xml父文件中的放置顺序和您期望的子项目被构建的顺序一样。下面我们看个示例。 pom.xml主文件如下： <project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.oreilly</groupId>
<version>1.0-SNAPSHOT</version>
<artifactId>my-app</artifactId>
<packaging>pom</packaging>
<modules>
<module>Common</module>
<module>Utilities</module>
<module>Application</module>
<module>WebApplication</module>
</modules>
</project>
我们需要确保WebApplication子模块包含了所有的三个jar包，所以需要将这些jar包声明为依赖项。在这个例子中，Utilities项目依赖于Common项目，所以Utilities项目中需要添加一个对Common项目的依赖。Application子模块也是同样的道理，因为它依赖于Common和Utilities项目，Utilities又赖于Common。如果这个例子中有60个子模块，并且它们都相互依赖，这会使得新开发者难以算出什么项目依赖于其它项目，所以这正好是要求确保pom.xml父文件中项目放置顺序要清除的原因。 以下是Utility模块的依赖项： <dependencies>
<dependency>
<groupId>com.oreilly</groupId>
<artifactId>Common</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
以下是如何声明Application模块的依赖项： <dependencies>
<dependency>
<groupId>com.oreilly</groupId>
<artifactId>Common</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.oreilly</groupId>
<artifactId>Utilities</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
最后是WebApplication模块的依赖项： <dependencies>
<dependency>
<groupId>com.oreilly</groupId>
<artifactId>Common</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.oreilly</groupId>
<artifactId>Utilities</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.oreilly</groupId>
<artifactId>Application</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
现在，我们只需为每个子模块的pom.xml文件添加一个元素来表明它们是一个逻辑构建的一部分： <parent>
<groupId>com.oreilly</groupId>
<artifactId>my-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
在pom.xml父文件所在的同一个目录中，存在有项目目录：Common, Utilities, Application, 和WebApplication。当我们在该目录中运行mvn package命令时，这些项目会按照依赖顺序而被构建。 插件和报表 Maven2.0有大量的插件可以使用。不幸的是，由于Maven的重写，Maven1.0的插件不能在2.0中使用。尽管如此，还是存在一些可以使用的Maven2.0的插件。下面pom.xml文件中的插件配置示例是直接从Maven2.0网站上得来的。这个插件是用来配置编译选项的。 <plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
Maven报表插件可以用来生成不同的报表，这些报表是在当你使用mvn site命令生成项目的站点时产生的。下面的例子展示了如何使用<reporting>元素来配置这类插件中的一个。 <reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
</plugin>
</plugins>
</reporting>
Maven Plugin Matrix是一个十分实用的工具，它能给出哪些Maven插件适合于哪些版本的Maven。 |
7726
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
