maven攻略(转)

Maven入门--概念与实例

    最近由于工作原因在研究、应用Maven,有了一些体会就写成了此文。本文虽然是Maven2的入门文章,但并不涉及Maven的历史、下载与安装,这些 内容可以到Maven的官方网站上了解。本文主要是关注Maven中的重要概念,并以一个实例来阐述使用Maven的基本方法。文末有例子代码下载的链接 。(2007.01.02最后更新)
注:转载时请注明原作者(jiangshachina)及出处(http://www.blogjava.net/jiangshachina )!

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/maven2/ 下载其中的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(Transitive Dependency),而不用显示的将这些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作为这两个工程的 一个 更高层次工程,即使用app和webapp成为这个工程的子工程。为了使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就不要再过多的使用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

 

 

 

 

Maven入门--较复杂的实例

本文将使用一个较复杂的实例,讲述如何定制目录布局(即不使用Maven标准目录布局),以及讲述一些关键插件的使用(配置)。为了方便其它朋友能够方便地使用该实例,后台数据库使用开源的面向对象数据库--db4o ,该数据库无需安装,已包含在与本文配套的实例中,文末附有该实例的下载链接。(2007.01.02最后更新)
注:转载时请注明原作者(jiangshachina)及出处(http://www.blogjava.net/jiangshachina )!

1 实例的构想
文章开头的摘要已经讲述了,本文仍然将以一个实例描述如何使用Maven,
该实例将使用非Maven标准的目录结构,并将呈现一些关键的Maven插件的配置与应用。 该实例是一个基于db4o的数据库Web应用。该应用本身十分简单,即从db4o数据库中查询出若干记录并将它们显现在Web页面中。
    该实例仍然由一个普通应用工程(demo-app)与一个Web应用工程(demo-web),以及这两个工程的父工程(demo)构成,最终的目标是将 Web应用工程制作成war文件,并部署到JBoss服务器中。启动服务器后,能够在页面中看到正确的查询结果。
    该实例使用Eclipse3.2 + JDK1.5.0_10 + Windows2000 开发。当然这仅仅只是我个人的开发平台,但该实例并不受限于此平台;由于我选择使用db4o针对JDK1.5的产品包,所以该实例只能运行在JDK1.5.0或更高版本的JDK/JRE中; 该工程中的所有文件都使用UTF-8 编码方式。

2 demo工程
demo工程是其它两个工程的父工程,它的主要职责是预定义子工程所需要依赖的jar文件(artifact),以及针对子工程所使用的插件进行通用配置。该工程完整的POM文件如下所示:

<project >
    <modelVersion> 4.0.0 </modelVersion>
    <groupId>mvn.demo</groupId>
    <artifactId>demo</artifactId>
    <packaging>pom</packaging>
    <version>
1.0 -SNAPSHOT</version>
    <description>Maven Demo Project</description>

    <modules>
        <module>demo-app</module>
        <module>demo-web</module>
    </modules>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>mvn.demo</groupId>
                <artifactId>demo-app</artifactId>
                <version>${project.version}</version>
            </dependency>
            <dependency>
                <groupId>mvn.demo</groupId>
                <artifactId>demo-web</artifactId>
                <version>${project.version}</version>
            </dependency>
            <dependency>
                <groupId>com.db4o</groupId>
                <artifactId>db4o-java5</artifactId>
                <version>
5.5 </version>
            </dependency>
            <dependency>
                <groupId>javax.servlet</groupId>
                <artifactId>servlet-api</artifactId>
                <version>
2.4 </version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>commons-configuration</groupId>
                <artifactId>commons-configuration</artifactId>
                <version>
1.2 </version>
                <exclusions>
                    <exclusion>
                        <groupId>dom4j</groupId>
                        <artifactId>dom4j</artifactId>
                    </exclusion>
                    <exclusion>
                        <groupId>xml-apis</groupId>
                        <artifactId>xml-apis</artifactId>
                    </exclusion>
                    <exclusion>
                        <groupId>xalan</groupId>
                        <artifactId>xalan</artifactId>
                    </exclusion>
                    <exclusion>
                        <groupId>xerces</groupId>
                        <artifactId>xercesImpl</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
        <groupId>junit</groupId>
         <artifactId>junit</artifactId>
           <version>
3.8.1 </version>
      <scope>test</scope>
    </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <configuration>
                    <encoding>UTF-
8 </encoding>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>
1.5 </source>
                    <target>
1.5 </target>
                    <encoding>UTF-
8 </encoding>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <addMavenDescriptor>false</addMavenDescriptor>
                    </archive>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <archive>
                        <addMavenDescriptor>false</addMavenDescriptor>
                    </archive>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <configuration>
                    <charset>UTF16</charset>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>
    预定义工程的依赖关系,就是把会被子工程依赖的artifact的详细信息(groupId,artifactId,version,...)先声明 到<dependencyManagement>中。然后子工程只需要声明使用某个artifact就可以了,即那时只需要设置 groupId和artifactId(甚至更少)就可以了。 <dependencyManagement>中声明的artifact并不一定真的会被使用到
2.1 声明依赖关系
    根据实际情况,
该实例 需要使用db4o针对 java5的产品包(jar文件)。由于该jar文件并不存在于Maven的中央仓库中,所以我们不能直接通过Maven获得该jar文件。我们只能另外 下载db4o-5.5(Java版)的压缩包,然后从压缩包内获得db4o-java5.jar。得到该jar后,必须先将它安装到Maven的本地仓库 中(安装方法参见资源[1],主题"向本地仓库安装文件时要生成POM文件"),以备后面的使用。此处将该artifact的groupId定义为com.db4o ,artifactId定义为db4o-java5 ,version自然就是5.5了(请见上述POM脚本)。
    由于该实例最终是一个Web应用,所以它至少需要依赖Servlet的包(servlet-api-2.4.jar),还需要commons- configuration-1.2.jar。这两个artifact都已经存在于Maven中央仓库中,所以我查找到它们后,按照Maven中央仓库的 命名将它们声明到了<dependencyManagement>中(请见上述POM脚本)。junit是进行单元测试时使用的 artifact,(假设)它肯定会被每个工程使用,所以没有将它设置到 <dependencyManagement>中,而直接设置到了 <dependency>中。
    细心的朋友肯定已经发现了,针对 commons-configuration的依赖声明处多了一些语句。从表面上看,应该是排除了4个artifact(dom4j, xml-apis xalan xerces )。 不错,就是排除了这4个jar文件(artifact)。如果有兴趣的话,可以将整个<exclusions>元素删除,然后再尝试一下制作 war文件。你会发现在WEB-INF/lib目录下存在着这4个artifact对应的jar文件。那我为什么要将它们“排除”呢?因为,它们是多余 的!即,它们对于我的这个Web应用来说,根本就是无用的!
    Maven2加入了一个很好的特性:自动加载“依赖的依赖(Transitive Dependency)” 。 以commons-configuration为例。为了能够让它运行正常,我们实际上还需要其它一些jar(artifact),如commons- collections,commons-lang,...。但这些artifact我都没有“显示”地声明需要依赖它们,但Maven会自动加载,因为
commons-configuration的POM文件将它们声明为了dependency
    既然那个4个artifact是commons-configuration的依赖,为什么会认为它们是无用的呢?实际上,它们就不应该被声明到 commons-configuration的依赖关系中。这是 commons- configuration开发者的失误,他们没有将依赖关系整理清晰,而将一些确实既不是runtime,更不是compile-time需要的 artifact放入到了依赖关系中。在Maven中央仓库中存在着很多这种情况,所以我们有时需要弄清楚“哪些文件是我们真正需要的,哪些是可以被清除 的”。但有时候,很难做到一个不漏。正是由于这一原因,自动加载Transitive Dependency这一极好的特性,有时让人十分无奈 ^_^
2.2 对插件进行基本配置
我们可以把对插件的全局性(如针对整个项目的)设置放到较高层次的POM文件中,因为它们被设置后,子工程们就会自然遵守它们,而且可以使每个子工程的情况都是一样的。
    在第1节中,已经表明该工程使用JDK1.5平台,并且所有文件都使用UTF-8
的编码方式 。而Maven默认使用JDK1.3级别的javac编译器;默认使用本地编码方式(简体中文Windows操作系统默认使用GBK编码方式)处理文件。这样就必须对Maven进行适当设置,以满足工程的实际需要。
    针对资源文件的处理,Maven使用maven- resources-plugin插件,需要将它的编码方式设置为UTF-8。编译Java源文件,是使用maven-compiler-plugin插 件,需要将它的source(Java源文件)与target(class文件)的级别都设置为1.5,另外还要将它的encoding方式设置为 UTF-8。(详细设置请见POM脚本)

3 demo-app工程
demo-app工程是一个普通应用程序工程,它用于处理和数据库相关的操作,如针对数据库的增、删、改、查等基本功能。该工程POM文件的主要内容如下所示:
<project >
    ......

    <build>
        <finalName>app</finalName>
        <directory>target</directory>

        <sourceDirectory>src/java</sourceDirectory>
        <outputDirectory>target/classes</outputDirectory>
        <resources>
            <resource>
                <directory>src/java</directory>
                <excludes>
                    <exclude>**/*.java</exclude>
                </excludes>
            </resource>
        </resources>

        <testSourceDirectory>src/test/java</testSourceDirectory>
        <testOutputDirectory>target/test-classes</testOutputDirectory>
        <testResources>
            <testResource>
                <directory>src/test/java</directory>
                <excludes>
                    <exclude>**/*.java</exclude>
                </excludes>
            </testResource>
        </testResources>
    </build>
</project>
    文章的开头已经提到,本实例将会使用定制的目录结构,但在前面却一字不提此事,现在将描述如何定制目录结构。Maven的标准目录结构其实是在Super POM中设置的,由于任何POM都会继承该POM,所以所有的工作都会默认使用标准目录结构。要定制目录,其实就是需要重新设置相关参数的值,即用新值覆 盖Super POM中的值。
[1]<finalName>,该元素指定了工程输出的artifact的名称,默认值为${artifactId}-${version},此处修改为app。
[2]<directory>,该元素指定了工程输出的目标目录。默认值为target,此处未修改变。
[3]<sourceDirectory>,该元素指定了Java源文件所在的目录。默认值为src/main/java,此处修改为src/java。
[4]<outputDirectory>,该元素指定了编译后的class文件的放置目录。默认值为target/classes,此处未作改变。
[5]<resources> <resource>, 该元素指定了Java源文件使用的资源文件的存放目录。默认值为src/main/resources,此处修改为src/java。由于在编码Java 源文件时,Maven会将资源路径中的文件全部拷贝到classes目录。而此时将Java资源文件目录与Java源文件目录,设置为同一目录,所以需要 将.java文件排除在资源文件的范畴之外( <exclude>**/*.java</exclude> )。
[6]
<testSourceDirectory>,该元素指定了单元测试Java源文件的放置目录。默认值为src/test/java,此处未作修改。
[7]
<testOutputDirectory>,该元素指定了单元测试Java源文件编译后的class文件放置目录。默认值为 target/test-classes,此处未作改变。
[8]
<testResources> <testResource>,该元素指定了单元测试Java源文件所使用的资源文件的放置目录。默认值为src/test/resources,此处修改为 src/test/java。并且也做了与 设置<resources> <resource>时相同的处理(排除Java源文件)。
    通过上述设置后,就可以拥有一个定制的Maven工程目录结构了。

4 demo-web工程
demo-web工程是整个应用最终的目标输出,因为此处的目的就是制作一个war文件,然后将它部署到JBoss服务器中。与demo-app工程相比,demo-web工程的POM文件主要有如下不同内容:

<project >
    ......
    <build>
        ......
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>
2.0.1 </version>
                <configuration>
                    <webappDirectory>target/${artifactId}</webappDirectory>
                    <warSourceDirectory>src/webapp</warSourceDirectory>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jboss-maven-plugin</artifactId>
                <version>
1.3.1 </version>
                <configuration>
                    <jbossHome>E:/jboss-
4.0.2 </jbossHome>
                    <serverName>default</serverName>
                    <fileName>
                        ${project.build.directory}/${project.build.finalName}.${project.packaging}
                    </fileName>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

可以看出不同之处就在于对maven-war-plguin及jboss-maven-plugin插件的配置与使用。
    Maven使用maven-war-plugin插件对Web工程制作war文件。由于本文使用了定制目录结构,这样则会使maven-war- plugin无法找到Web工程的Web Root目录(默认是src/main/webapp),所以需要对该插件进行适当地配置。<warSourceDirectory>就是 Web工程的Web Root目录,此处设置为;<webappDirectory>是制作war文件之前,相当于是一个被打开(exploded)的war文件 的根目录(默认是target/artifactId-version)。
    该工程的脚本中,还使用了一个JBoss插件。该插件可以将制作好的war文件部署(实质上是拷贝)到指定的JBoss部署目录 中。<jbossHome>是JBoss的安装根目录,<serverName>指JBoss Server的名称,<fileName>是被部署war文件的名称。

参考资源
[1]Maven入门--概念与实例. http://www.blogjava.net/jiangshachina/archive/2006/09/01/67080.html
[2]Maven + Continuum Weed. http://www.blogjava.net/jiangshachina/archive/2006/09/11/68944.aspx
[3]Maven POM Reference. http://maven.apache.org/pom.html
[3]db4o. http://www.db4objects.com
本文实例下载地址-- http://www.blogjava.net/files/jiangshachina/mvn-demo.rar

 

 

 

 

 

 

Maven2的archetype插件新特性:

在最新的Maven archetype插件的2.0-alpha-2版本中,archetype的创建方式和之前大不一样,将使用 archetype:generate 来创建项目,而不是之前的 archetype:create。archetype:generate方式创建项目将更加人性化,而且对于各种archetype的归类和项目创建提 示帮助都很大,如你还没有使用过,你只需输入mvn archetype:generate就可以体验到啦。
为了更好地体验archetype:generate的功能,我们需要讲述一下新的archetype:generate是如何查找各个 archetype jar文件的。archetype:generate是通过archetypeCatalog设置来查找相关的archetype,这里 archetype catalog相当于archetype库,一个catalog包含多个archetype。这个库是什么样的呢,其实就是一个描述文件,名称为 archetype-catalog.xml,格式如下:
<?xml version="1.0" encoding="UTF-8"?>
<archetype-catalog>
<archetypes>
<archetype>
<groupId>org.mvnsearch.ridd</groupId>
<artifactId>ridd-archetype-simple</artifactId>
<version>1.0</version>
<repository>http://www.mvnsearch.org/maven2</repository>
<description>Create RIDD Web Application</description>
</archetype>
</archetypes>
</archetype-catalog>
通过该xml文件,就可以将相关的archetype组织在一起。     我们使用archetype:generate时,需要通过archetypeCatalog来给其制定一个archetype库,这里库分为3种类 型:1. 缺省库, 2. 用户库, 3. 第三方库。缺省库,很容易理解,就是archetype插件自身就包含的各个archetype,如果你没有指定任何库,缺省库就会其作用,在 archetype插件中使用internal对其进行命名。用户库是指最终用户平时自己使用的库,这个库的文具存放于file://~/.m2/archetype-catalog.xml , 在archetype插件中通过local对其进行命名。第三方库,也就是以上两者之外的所有库,如存放于本地磁盘的一个目录,远程服务上等。如果公司内 部有很多archetype,就可以建一个这样的库,存在服务器上,大家可以进行共享。第三方库中,由于repo1.maven.org是官方支持的,所 以有一个别名:remote,用于标识官方的库。
现在如果你想创建一个archetype,首先确定库,然后根据archetype:generate提供的提示进行创建即可。以下是常见的几种方式:
mvn archetype:generate   调用internal库进行创建
mvn archetype:generate -DarchetypeCatalog=local   调用local库进行创建
mvn archetype:generate -DarchetypeCatalog=http://www.mvnsearch.org/maven2 调用http://www.mvnsearch.org/maven2/archetype-catalog.xml 提供的库进行创建。
了解这些以后,如果你有相关的archetype想和别人共享,只要将库的地址发给对方就可以啦,依据archetype创建将非常简单。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值