當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

[原创]Maven实战-读书笔记

發布時間：2023/12/18 编程问答 23 豆豆

生活随笔收集整理的這篇文章主要介紹了 [原创]Maven实战-读书笔记小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Maven讀書筆記

依賴

快捷鍵：Alt+Shift+X M

使用ArcheType來創建Maven項目骨架：

Maven中坐標的定義

依賴范圍

依賴傳遞

依賴調解

可選依賴

最佳實踐

Maven倉庫

構件的概念

構件在Maven倉庫中的路徑

Maven倉庫

本地倉庫：

遠程倉庫：

遠程倉庫的配置

遠程倉庫的認證

快照版本

什么是快照版本？

為什么需要快照版本？

在什么情況下使用快照版本？

從倉庫中解析依賴的策略

鏡像

倉庫搜索服務

生命周期和插件

概念

生命周期

插件目標

生命周期階段與插件的綁定

手工綁定生命周期階段與插件目標

插件配置

獲取插件信息

插件前綴

聚合與繼承

導入依賴

反應堆

裁剪反應堆

用Nexus創建私服

下載安裝

Nexus倉庫的分類

下載遠程倉庫的索引

配置本機從私服下載構件

部署構件至私服

使用Maven進行測試

測試類的模式

使用參數

測試報告

測試覆蓋率

打包測試代碼

使用Hudson進行持續集成

概念

Hudson

使用Maven構建Web應用

使用Jetty-maven-plugin對web應用進行測試

使用Cargo實現自動化部署

版本管理?

依賴

快捷鍵：Alt+Shift+X M

在Eclipse中運行Maven命令的快捷方式是：Alt+Shift+X M。按下Alt+Shift+X之后，從彈出的菜單中可以看到，選擇R是：run on server。所以運行于服務器的快捷鍵是：Alt+Shift+X R

使用ArcheType來創建Maven項目骨架：

mvn archetype:generate

Maven中坐標的定義

以nexus-indexer為例：

<groupId>org.sonatype.nexus</groupId>

<artifactId>nexus-indexer</artifactId>

groupId:maven項目(模塊)的上一級項目，比如nexus-indexer屬于nexus這個項目，這里的命名使用和Java中包名類似的方式，域名的倒寫。

artifactId:maven模塊的名字，一般以上級項目作為前綴，比如這里的:nexus-indexer

version:版本號

packaging(可選的):默認是jar，可以指定為war或jar

還有一個坐標：classifier，用以描述附屬構件，不能直接定義它，它是由附加的插件幫助生成的。例如可以通過一些插件來生成nexus-indexer模塊的javadoc和sources，這些屬于附屬構件。

項目構件的文件名與坐標名是對應的，一般的規則是：artifactId-version[-classifier].packaging。所以nexus-indexer的主構件文件名可以是：nexus-indexer-2.0.0.jar，而附屬構件可以是：nexus-indexer-2.0.0-javadoc.jar。packaging不一定就是文件擴展名，比如packaging為maven-plugin的構件的擴展名是jar。

依賴范圍

Maven在編譯(compile)，編譯并執行測試(test)，運行(runtime)這三種環境下使用三種不同的classpath，依賴范圍就是用來控制這三種classpath的。有六種依賴范圍：

compile:默認的依賴范圍。對編譯，測試，運行三種classpath都有效；
test:只對測試classpath有效，典型的例子是Junit；
runtime:對測試和運行classpath有效，典型的例子是JDBC驅動的實現，編譯的時候只需要JDK提供的JDBC接口，不需要實現。
provided:只對編譯和測試有效，運行時無效。典型的例子是servlet-api，因為在運行時，容器必然會提供這些接口，不需要再包含。
system:它和provided一樣，不過它依賴的包不是通過Maven倉庫獲取，而是指定依賴文件的路徑。
import:導入依賴范圍。它不對classpath造成影響。

依賴傳遞

A依賴B，B依賴C，那么A可能會間接依賴到C，規律是這樣的：

如果B對C的依賴范圍是Compile，那么A對C的依賴和A對B的依賴是一樣的。
如果B對C的依賴范圍是Test，那么A不依賴于C
如果B對C的依賴范圍是runtime，那么A如果對B的依賴范圍是Compile，那么A對C的依賴范圍是Runtime，其它情況下，B對C的依賴都會傳遞給A。
如果B對C的依賴范圍是provided，那么只傳遞B對C的provided依賴給A；

如下表所示(最上面一行表示B對C的依賴范圍，最左側一列表示A對B的依賴范圍，中間的單元格表示A對C的依賴范圍)：

?	compile	test	runtime	provided
compile	compile	-	runtime	-
runtime	runtime	-	runtime	-
test	test	-	test	-
provided	provided	-	provided	provided

依賴調解

依賴調解遵循下面的兩個原則：

路徑最近這優先：比如，A->B->C->X(1.0)，,A->D->X(2.0)，此時A依賴于X(2.0)
路徑相同時，第一聲明者優先：比如，A->B->Y(1.0)，A->C->Y(2.0)，此時根據在Pom文件中聲明的順序來決定哪個版本的Y被解析使用。

可選依賴

如果A依賴B，而B對X和Y的依賴都是可選的，那么按照Maven的規則，A就不會依賴于X和Y，但是實際運行的時候，A其實是需要X或Y的，所以在A中需要顯示的聲明對X或Y的依賴。為什么會出現這種情況呢？舉個例子就明白了，例如B實現某個特性，既可以基于MySQL數據庫，也可以基于postgresql數據庫，這兩個依賴對B都是可選的，但是當A使用B的時候，必須確定一種底層數據庫實現，要么選擇MySQL，要么選擇postgresql。

不推薦使用可選依賴。最好的做法是，B構建兩個Jar包，分別用于支持MySQL和postgresql。這也是軟件設計里面的單一職責原則。

最佳實踐

排除依賴：排除依賴的理由就是不想引入間接依賴的某個Jar包，而使用另一個等價的Jar包替換之(可能的原因有：間接依賴引入的是一個SNAPSHOT--不穩定版本，需要使用穩定版本替代之，或者是簡介依賴引入的是一個受版權保護的版本，在Maven中央倉庫里面沒有該Jar包，需要用開源版本替換之)
為一類依賴統一定義版本：比如account-email項目依賴于springframework-core,springframework-context,springframework-context-support,springframework-beans，它們都是同一個版本，可以定義一個變量來保存版本：

<springframework.version>2.5.6</springframework.version>

</properties>

定義依賴的時候，引用該版本：

<groupId>org.springframework</groupId>

<artifactId>spring-context</artifactId>

<version>${springframework.version}</version>

</dependency>

- 分析依賴。可以使用這些命令來分析依賴：

mvn dependency:list:列出所有的依賴包
mvn dependency:tree: 列出依賴關系樹
mvn dependency:analyze: 分析聲明但未使用的依賴和使用但未聲明的依賴。

Maven倉庫

構件的概念

Maven中，任何一個依賴、插件或者項目構建的輸出，都可以成為構件。

構件在Maven倉庫中的路徑

構件在Maven倉庫中的路徑分成如下幾個部分：

基于groupId的準備路徑
基于artifactId的準備路徑
基礎版本信息：所謂基礎版本是指在SNAPSHOT版本中，取除SNAPSHOT以外的版本信息，比如1.0-SNAPSHOT的基礎版本是1.0。
構件的文件名：{artifactId}-{version}-{classfier}.{extension}，這里的version是整個版本信息，不是基礎版本信息。

例如這個構件：groupId=org.testng ?artifactId=testng version=5.8-SNAPSHOT classfier=jdk15 packaging=jar 它的Maven倉庫路徑為：

org/testng/testng/5.8/testng-5.8-SNAPSHOT-jdk15.jar

Maven倉庫

Maven倉庫分成下面幾類：

按地理位置分為：本地倉庫和遠程倉庫
遠程倉庫又分為：中央倉庫、私服和其它公共庫。

本地倉庫：

Maven在編譯和測試時，總是使用本地倉庫中的依賴文件。一個構件進入本地倉庫有兩種途徑：

從遠程倉庫下載到本地倉庫

將本地構件安裝到Maven倉庫中：mvn clean install

遠程倉庫：

本地倉庫好比是自己的書房，遠程倉庫好比是書店(比如amazon)，要想看一本書，需要把書從遠程倉庫收藏到自己的本地倉庫中。

中央倉庫：

中央倉庫就是默認的遠程倉庫。中央倉庫的定義位于{$MAVEN_HOME}/lib/maven-model-builder-3.0.4.jar這個包里面的：\org\apache\maven\model\pom-4.0.0.xml文件中，這個POM文件也是所有Maven項目都會繼承的超級POM。

私服：

私服是架設在局域網內的倉庫服務，它代理廣域網上的遠程倉庫。局域網內的用戶向私服請求構件，如果私服上不存在，則從外部的遠程倉庫上下載，緩存到私服上之后，再為局域網內的下載請求提供服務。也可以將構件安裝到私服，一共團隊內使用。

私服的架構如下所示：

搭建私服有下列的好處：

節省外網帶寬

加速Maven構建：訪問局域網內的私服速度要快得多

部署第三方構件：組織內部生成的私有構件需要安裝在私服上供團隊內使用，而且一些受版權保護的構件(比如Oracle的JDBC驅動)也不會出現在中央倉庫上，這些需要安裝到私服上。

增強穩定性，增強控制。

減輕對中央倉庫的壓力：這是從中央倉庫的角度來說的，Maven鼓勵建立私服，而不是讓所有開發人員都直接訪問中央倉庫。

遠程倉庫的配置

從超級POM文件中可以看到，默認的中央倉庫的配置信息如下所示：

?<repositories>

???<repository>

?????<id>central</id>

?????<name>Central Repository</name>

?????<url>http://repo.maven.apache.org/maven2</url>

?????<layout>default</layout>

?????<snapshots>

???????<enabled>false</enabled>

?????</snapshots>

???</repository>

?</repositories>

可以看到，一個遠程倉庫的配置在<repositories>元素的<repository>子元素下面，下面的屬性需要說明：

id：每一個倉庫聲明的id都必須是唯一的，默認的中央倉庫的id為central，如果其它倉庫聲明也是用該id，那么會覆蓋中央倉庫的配置。
url：指向倉庫的地址，在瀏覽器中可以通過該url訪問構件
layout：值default表示使用maven2和maven3的布局，而不是用maven1的布局
snapshots：enabled值為false表示，關閉中央倉庫對快照版本下載的支持。與這個屬性類似的一個屬性是releases，它也有eabled屬性，值true表示支持發布版本的下載。releases的定義是這樣的：

???????<enabled>true</enabled>

???</releases>

對于releases和snapshots，除了enabled之外，還有兩個屬性：updatePolicy和checksumPolicy，分別控制從遠程倉庫檢查更新和校驗文件的策略，具體值如下表所示：

屬性	取值	說明
updatePolicy	never	從不檢查更新
?	daily	默認值。每天檢查一次更新。
?	always	每次構建都檢查更新
?	interval:X	每個X分鐘檢查一次更新
checksumPolicy	warn	默認值。校驗失敗時輸出警告信息。
?	fail	校驗失敗時，構件的構建會失敗。
?	ignore	忽略校驗錯誤。

遠程倉庫的認證

在settings.xml中配置倉庫的認證信息，如下所示：

……

<id>deploymentRepo</id>

<username>repouser</username>

<password>repopwd</password>

</server>

</servers>

……

</settings>

其中的id屬性必須和POM文件中配置的repository元素的id完全一致(見上一節里面配置的repository)

部署至遠程倉庫

往往日常開發的構件需要部署到遠程倉庫中，需要在項目的POM文件中，配置distributionManagemant元素，如下所示：

……

<id>proj-release</id>

<name>proj release repository</name>

<url>http://192.168.1.100/repositories/proj-releases</url>

</repository>

<id>proj-snapshot</id>

<name>Proj Snapshot Repository</name>

<url>http://192.168.1.100/content/repositories/proj-snapshots</url>

</snapshotRepository>

</distributionManagement>

……

</project>

使用命令：mvn clean deploy 將構件部署到遠程倉庫。Maven會判斷出當前構件時快照版本還是發布版本。

快照版本

什么是快照版本？

類似2.1-SNAPSHOT、2.1-20091214-1413-13這種版本就是快照版本，在將快照版本發布到私服的過程中個，Maven會自動為構件打上時間戳，比如，20091214-1413-13就表示2009年12月14日，14點13分的第13個版本。有了時間戳，Maven就能找到2.1-SNAPSHOT快照版本的最新文件。默認情況下，Maven每天檢查一次快照版本的更新。可以使用-U參數(比如，mvn clean install -U )來強制更新構件。

為什么需要快照版本？

在團隊內部，當一個模塊的開發還未成熟，其它開發人員又需要使用該構件時，可以使用快照版本來解決依賴問題。因為不穩定的Jar包需要頻繁更新，如果不使用快照，而是用發布版本，那么需要經常修改POM文件中的版本號，或者重復部署同樣的版本號供Maven下載--這需要清除本地倉庫才能使Maven下載同一個版本的構件。

在什么情況下使用快照版本？

快照版本只能用于組織內部。項目不應該依賴于任何組織外部的快照版本，因為快照版本是不穩定的，隨時可能會更新，這樣會導致項目的構建今天是成功的，而由于外部快照版本的變化，以后的構建卻不一定成功。

從倉庫中解析依賴的策略

總體的原則是這樣的：

如果本地倉庫中沒有需要的構件，則從遠程倉庫下載
當依賴版本為SNAPSHOT時，Maven自動找到最新的快照
當依賴版本為RELEASE或LATEST時，Maven會計算出最新的發布版本和最新的版本(包括快照版本)的值，然后在本地倉庫或遠程倉庫中查找該版本的構件。不推薦使用RELEASE和LATEST，因為它們帶有不確定性，構件的發布版本或最新版本發生變化時，使用者不會得到通知，所以出錯時，往往不方便定位問題。

鏡像

如果倉庫X可以提供倉庫Y中存儲的所有內容，則認為X是Y的一個鏡像。在settings.xml中配置鏡像：

<id>internal-repository</id>

<name>Internal Repository Manager</name>

<url>http://192.168.1.100/maven2</url>

</mirror>

</mirrors>

可以將私服配置為所有外部公共倉庫的鏡像，因為私服可以代理所有的公共倉庫。

倉庫搜索服務

可以在這些網站搜索Jar包：

http://repository.sonatype.org(推薦)
http://www.jarvana.com/jarvana(無法訪問)
http://mvnrepository.com

生命周期和插件

概念

生命周期

Maven對軟件構建的整個生命周期做了定義，這個定義基本能滿足所有軟件項目構建的需求，包括：項目的清理、初始化、編譯、測試、打包、集成測試、驗證、部署和站點生成等。生命周期的每一個階段都由插件來實現。Maven為每一個階段關聯了默認插件。比如針對編譯的插件有：maven-compiler-plugin，針對測試的插件有：maven-surefire-plugin等。

Maven中有三套生命周期：clean、default、site。每個生命周期都有自己的階段，生命周期之間是獨立的。具體的生命周期可以不用管，只要知道使用下面的命令就可以了：

$mvn clean：執行clean生命周期的clean階段
$mvn test：執行default生命周期的test階段
$mvn clean install：執行clean生命周期的clean階段，然后執行default生命周期的install階段

插件目標

Maven只定義了抽象的生命周期，具體的功能由插件來完成。每個插件往往會實現多個功能，這些功能就成為插件目標。比如，maven-dependency-plugin這個插件的目標有：dependency:analyze、dependency:tree、dependency:list等。maven-compiler-plugin插件有compiler:compile目標，maven-surefire-plugin有surefire:test目標。(surefire: [?????fa??]

)

生命周期階段與插件的綁定

Maven的生命周期與插件目標相互綁定，以完成實際的構建任務。如下圖所示：

Maven默認為主要的生命周期階段都綁定了插件，下表是default生命周期與插件的綁定關系：

生命周期階段	插件目標	執行任務
process-resources	maven-resources-plugin:resources	復制主資源文件至主輸出目錄
compile	maven-compiler-plugin:compile	編譯主代碼至輸出目錄
process-test-resouces	maven-resources-plugin:testResources	復制測試資源至測試輸出目錄
test-compile	maven-compiler-plugin:compiler	編譯測試代碼至測試輸出目錄
test	maven-surefire-plugin:test	執行測試用例
package	maven-jar-plugin:jar	創建項目Jar包
install	maven-install-plugin:install	將項目輸出構件安裝到本地倉庫
deploy	maven-deploy-plugin:deploy	將項目輸出構件部署到遠程倉庫

default生命周期中的一些階段沒有綁定任何插件，因此沒有任何實際行為。

手工綁定生命周期階段與插件目標

下面的例子演示了手工將maven-source-plugin的jar-no-fork目標與default生命周期的verify階段綁定，用以創建項目的源碼jar包：

<build>

?????<plugin>

?????<groupId>org.apache.maven.plugins</groupId>

???????<artifactId>maven-source-plugin</artifactId>

???????<version>2.1.1</version>

???????<executions>

?????????<execution>

???????????<id>attach-sources</id>

???????????<phase>verify</phase>

???????????<goals>

?????????????<goal>jar-no-fork</goal>

???????????</goals>

?????????</execution>

???????</executions>

?????</plugin>

</plugins>

???</build>

插件配置

可以通過命令行和POM文件來配置插件的參數;

命令行方式：$mvn install -Dmaven.test.skip=true
POM文件方式：

<build>

……

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

????<source>1.5</source>

????<target>1.5</target>

????</configuration>

</plugin>

……

</plugins>

</build>

獲取插件信息

從下面站點可以獲取插件信息，以了解插件有哪些可配置點：

http://maven.apache.org/plugins/index.html
http://mojo.codehaus.org/plugins.html

也可以使用mvn:help命令來了解某一插件的信息：

mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin:2.1

可以直接用目標前綴替代adgroupId:artifactId:version，如下所示：

mvn help:describe -Dplugin=compiler

帶上-Ddetail可以看到詳細信息：

mvn help:describe -Dplugin=compiler -Ddetail

輸出結果中列舉出了該插件的目標，也給出了目標前綴，方便了在命令行執行目標：

Name: Maven Compiler Plugi

Description: The Compiler Plugin is used to compile the sources of your project.

Group Id: org.apache.maven.plugins

Artifact Id: maven-compiler-plugin

Version: 2.1

Goal Prefix: compiler

This plugin has 3 goals:

compiler:compile

?Description: Compiles application sources

compiler:help

?Description: Display help information on maven-compiler-plugin.

???Call

?????mvn compiler:help -Ddetail=true -Dgoal=<goal-name>

???to display parameter details.

compiler:testCompile

?Description: Compiles application test sources.

For more information, run 'mvn help:describe [...] -Ddetail'

插件前綴

插件前綴和groupId:artifactId是一一對應的，這種匹配關系存儲在倉庫元數據中，位于groupId/mavenmetadata.xml中，這里的groupId是公共插件倉庫的默認groupId，有兩個取值：org.apache.maven.plugins和org.codehaus.mojo，也可以是自定義插件倉庫的groupId。執行插件目標的時候，Maven會根據插件前綴找到對應的插件信息。

聚合與繼承

聚合與繼承都是為了方便管理項目，更好的在Maven中應用軟件編程的優秀思想。聚合，是將多個Maven項目聚合到一個項目中，便于統一編譯，測試，打包等構建操作。繼承，是將面向對象的繼承思想應用到項目組織里面，使用繼承可以減少重復配置，使項目之間的結構更合理。聚合與繼承的功能各不相同，但是可以將父模塊和聚合模塊合并成一個模塊。

聚合項目其實是一個空殼Maen項目，它只有一個POM文件，該POM的內容為：

<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">

<groupId>com.juvenxu.mvnbook.account</groupId>

<artifactId>account-aggregator</artifactId>

<version>0.0.1-SNAPSHOT</version>

<name>Account Aggregator</name>

<module>account-email</module>

<module>account-persist</module>

<module>account-parent</module>

</modules>

</project>

被繼承的項目作為其它項目的父項目，可以集中定義一些公用的依賴，變量，以及groupId，version。子項目中不需要再定義這些內容。父項目的例子：

……

<groupId>com.juvenxu.mvnbook.account</groupId>

<artifactId>account-parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

<name>Account Parent</name>

<springframework.version>2.5.6</springframework.version>

<junit.version>4.7</junit.version>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

<groupId>org.springframework</groupId>

<artifactId>spring-core</artifactId>

<version>${springframework.version}</version>

</dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>${junit.version}</version>

</dependency>

……

紅色的內容都是可以被子項目繼承的部分。父項目使用<dependencyManagement>來管理依賴，dependencyManagement中定義的依賴不會為子項目增加依賴，但是它可以限制項目中依賴包的版本號和范圍。比如，在子項目中只需這樣配置就行了：

???<dependency>

<groupId>org.springframework</groupId>

???<artifactId>spring-core</artifactId>

???</dependency>

?????<groupId>junit</groupId>

?????<artifactId>junit</artifactId>

</dependency>

……

</dependencies>

子項目中不需要聲明依賴的版本號，也不需要聲明依賴的范圍。使用dependencyManagement可以統一管理項目中依賴的版本號。同理pluginManagement也可以用來管理插件。

導入依賴

dependencyManagement可以用來導入范圍為import的依賴。如果有多個項目，它們的依賴版本基本是一致的，就可以定義一個使用dependencyManagement專門管理依賴的POM，然后在各個項目中導入這些依賴，子項目中的配置如下所示：

???<dependencies>

???<dependency>

???<groupId>com.juvenxu.mvnbook.account</groupId>

???<artifactId>account-parent</artifactId>

???<version>1.0-SNAPSHOT</version>

???<type>pom</type>

???<scope>import</scope>

???</dependency>

???</dependencies>

</dependencyManagement>

反應堆

反應堆是指，在多模塊的Maven項目中，所有模塊組成的一個構建結構。對于單模塊項目，反應堆就是該模塊本身，但是對于多模塊項目，反應堆需要計算各模塊之間的繼承與依賴關系，以便確定出合理確的構建順序。

反應堆的構建順序是這樣的：Maven按順序讀取POM，如果該POM沒有依賴模塊，那么就構建該模塊，否則就先構建其依賴模塊。

裁剪反應堆

用下面的命令可以指定只構建反應堆中的部分模塊，而不是整個反應堆都構建：

-pl 指定構建的模塊，用逗號隔開多個模塊：

mvn clean install -pl account-email,account-persist

-am 同時構建所列模塊的依賴模塊：

mvn clean install -pl account-email -am

-amd同時構建依賴于所列模塊的模塊

mvn clean install -pl account-email -amd

用Nexus創建私服

下載安裝

Nexus有免費版和專業版，免費版的下載地址是：http://www.sonatype.org/nexus/go

這是直接解壓就能運行的，它自帶jetty容器。還有一種war包形式發布的版本，需要放在容器里面才能運行。也在同一個頁面下載。

解壓后，可以按下面的方式運行：

nexus-2.3.1-01\bin\nexus.bat -start

然后在瀏覽器里面訪問：

http://localhost:8081/nexus

管理員的默認用戶名和密碼分別是:admin/admin123

Nexus倉庫的分類

hosted：私服本地的倉庫
proxy：代理的遠程倉庫
group：倉庫組，它把多個本地和遠程倉庫合并在一起
virtual：不用管

下載遠程倉庫的索引

需要手工開啟對遠程倉庫索引的下載，選擇一個倉庫，然后在屬性里配置：

配置本機從私服下載構件

　<mirrors> ????

?????<mirror>

?????<id>central</id>

?????<mirrorOf>*</mirrorOf>

?????<url>http://localhost:8081/nexus/content/groups/public/</url>

???</mirror>

?</mirrors>　　

??

???<profiles>

???????<id>JDK1.6</id>

???????<activation>

???????????<activeByDefault>true</activeByDefault>

???????????<jdk>1.6</jdk>

???????</activation>

???????<properties>

???????????<maven.compiler.source>1.6</maven.compiler.source>

???????????<maven.compiler.target>1.6</maven.compiler.target>

???????????<maven.compiler.compilerVersion>1.6</maven.compiler.compilerVersion>

???????</properties>

???</profile> ?

?????<profile>

?????<id>central</id>

?????<repositories>

???????<repository>

?????????<id>central</id>

?????????<url>http://central</url>

?????????<releases><enabled>true</enabled></releases>

?????????<snapshots><enabled>true</enabled></snapshots>

???????</repository>

?????</repositories>

????<pluginRepositories>

???????<pluginRepository>

?????????<id>central</id>

?????????<url>http://central</url>

?????????<releases><enabled>true</enabled></releases>

?????????<snapshots><enabled>true</enabled></snapshots>

???????</pluginRepository>

?????</pluginRepositories>

???</profile>

?</profiles>

???<activeProfile>central</activeProfile>

????<activeProfile>JDK1.6</activeProfile>

?</activeProfiles>

</settings>

部署構件至私服

在項目的POM文件中需要做如下配置：

???<distributionManagement>

????????<repository>

????????????<id>nexus-releases</id>

???????????<name>Nexus Releases Repository</name>

??????????<url>http://localhost:8081/nexus/content/repositories/releases</url>

???????</repository>

???????<snapshotRepository>

?????????????<id>nexus-snapshots</id>

?????????????<name>Nexus Snapshots Repository</name>

????????????<url>http://localhost:8081/nexus/content/repositories/snapshots</url>

???????</snapshotRepository>

??</distributionManagement>

</project>

配置服務器認證信息：

????<server>

?????<id>releases</id>

?????<username>admin</username>

?????<password>iapppay</password>

???</server>

???<server>

?????<id>snapshots</id>

?????<username>admin</username>

?????<password>iapppay</password>

???</server> ?

</servers>

使用Maven進行測試

測試類的模式

測試類滿足下面的命名模式才會被maven-surefire-plugin作為測試類來執行：

**/Test*.java
**/*Test.java
**/*TestCase.java

以Tests結尾的測試類不會被Maven執行。

使用參數

可以使用-DskipTests來跳過測試：

$mvn package -DskipTests

也可以使用-Dtest參數來限定需要執行的測試：

$mvn package -Dtest=RandomGeneratorTest

Maven還支持在-Dtest參數中指定更高級的正則表達式：

$mvn package -Dtest=Random*Test

也可以指定多個測試用例，測試用例之間用逗號分隔：

$mvn package -Dtest=RandomGeneratorTest,AccountCaptchaServiceTest

測試報告

測試報告位于：target\surefire-reports目錄下，有兩種形式的報告：txt格式和XML格式。

測試覆蓋率

通過Mavne的Cobertura插件可以檢測出代碼的測試覆蓋率：

$mvn cobertura:cobertura

測試覆蓋率報告位于：target\site\cobertura目錄下

打包測試代碼

通過配置maven-jar-plugin插件可以打包測試代碼：

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-jar-plugin</artifactId>

<goals>

</goals>

</execution>

</executions>

</plugin>

</plugins>

這樣在運行 $mvn package后，會生成一個測試代碼的Jar包，比如：

account-captcha-0.0.1-SNAPSHOT-tests.jar

使用Hudson進行持續集成

概念

持續集成想要達到的目的：

快速集成
高頻率自動集成
自動構建：編譯、測試、打包、部署、審查
集成團隊所有成員的最新源碼
集成結果及時反饋給開發人員
集成結果自動部署到私服中

一個典型的持續集成場景如下圖所示：

一次完整的集成往往包括以下6個步驟：

持續編譯：CI服務器按一定頻率檢查源碼控制系統，如果有新代碼就觸發一次集成

持續數據庫集成：每次發現新的SQL腳本，就清理集成環境的數據庫，重新創建表結構，并填入預備的數據。

持續測試：每次集成式運行自動化測試

持續審查：審查測試覆蓋率報告，CheckStyle報告，PMD報告等

持續部署

持續反饋

持續集成帶來的好處：

盡早暴露問題
減少重復操作
簡化項目發布
建立團隊信心：因為持續集成會覆蓋大部分項目中的問題

Hudson

Hudson比較容易安裝和運行。具體的配置可以參考第11章 “使用Hudson進行持續集成”。

使用Maven構建Web應用

一個典型的War文件的目錄結構是：

METE-INF目錄存放打包元數據信息，一般不用管

WEB-INF目錄下必須包含一個Web資源表述文件web.xml，

classes和lib都會在運行時加入到classpath中

Maven打包的War文件和jar文件的區別在于，war文件有一個web資源目錄，其默認位置是：src/main/webapp，一個典型的Web項目的Maven結構如下所示：

Maven打包的War包結構和通常的War包結構有一個對應關系，在src/main下有一個webapp目錄，該目錄下有web.xml，jsp，html，js，css等文件和目錄。

可以使用<build>標簽的finalName屬性來指定最終打的war包的名字：

<build>

<finalName>account</finalName>

……

</build>

使用Jetty-maven-plugin對web應用進行測試

有一個大原則：

可以用單元測試覆蓋的代碼就不應該依賴于Web頁面測試
web頁面測試僅限于對JSP，CSS，JS的修改，其它代碼都應該用單元測試覆蓋

jetty-maven-plugin可以把我們對代碼的修改及時部署到測試服務器上，我們可以實時測試對代碼的修改，這可以加速開發。可以像下面這樣啟動jetty:

$mvn jetty:run -Djetty.port=9999

如果不指定jetty.port，默認是8080端口。

不過，因為只有adgroupId是org.apache.maven.plugins和org.codehauls.mojo的插件才支持簡化的命令行調用，比如mvn help:system這種。jetty的groupId是org.mortbay.jetty，要想直接使用jetty:run，還需要在maven的settings.xml文件中作如下的配置：

<pluginGroup>org.mortbay.jetty</pluginGroup>

</pluginGroups>

</settings>

在POM文件中需要對Jetty的參數做配置：

<groupId>org.mortbay.jetty</groupId>

<artifactId>jetty-maven-plugin</artifactId>

<contextPath>/account</contextPath>

</webAppConfig>

</configuration>

</plugin>

</plugins>

</pluginManagement>

經過試用，jetty:run確實很方便，修改jsp，或js代碼之后，不需要重新構建，打包，部署，直接就能看到效果，加快了開發的速度。

使用Cargo實現自動化部署

cargo可以幫助實現在各種容器下的自動部署。

cargo的主頁：http://cargo.codehaus.org/Home

版本管理

下圖可以說明快照版本和發布版本之間的演變：

版本的含義，以1.3.4-beta-2為例：

1：表示該版本是第一個重大版本

3：表示這是基于重大版本的第三個次要版本

4：表示該次要版本的第4個增量

beta-2：表示該增量的某一個里程碑

<主版本>.<次版本>.<增量版本>-<里程碑版本>

靈活的構建

生成項目站點

2013年4月12日0:13:42 完

轉載于:https://www.cnblogs.com/seeker2012/archive/2013/04/28/maven_note.html

總結

以上是生活随笔為你收集整理的[原创]Maven实战-读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： AutoHotkey调用VBA实现批量精
下一篇： FreeSql （二十二）Dto 映射查