一些零散的筆記：
mvn命令若干：
mvn -h，不會用時，可尋求幫助。
mvn clean compile，將.java類編譯為.class文件；
mvn clean test, 執行單元測試。本質上，還是執行了一個完整的生命周期，clean:clean, resources:resources, compiler:compile, resources:testResources, compiler:testCompile
mvn clean package，進行打包。
mvn clean install –Dmaven.test.skip
mvn clean install，將某jar包安裝到maven本地倉庫中。
mvn archetype:generate，快速的搭建項目骨架，輸入一些groupId/artifactId/version等信息，由mvn插件自動生成一些必要的依賴和項目骨架。
這三個標簽，形成一個小單元（所謂的依賴的“基本坐標”）
<groupId>, 定義組，如com.googlecode.myapp
<artifactId>, 定義組內一個具體的條目，如helloworld。（com.googlecode.myapp.helloworld）
<version>，定義個版本號。一般開發中的包，1.0-SNAPSHOT即用snapshot作為后綴。
以下為非必須（但要了解）：
<type> ，package類型，一般不用寫，默認是jar。還有，jar/war/pom/maven-plugin/ear等。
<scope>，依賴范圍，我簡記為“能見度”。例如，
test=測試。僅對測試類有效，在java類中引入會報錯的。例如，JUnit
compile=編譯+測試+運行，默認不寫則是這種編譯方式，對於編譯、測試、運行都有效。例如，spring-core
provided=編譯+測試。對於編譯和測試有效，運行時無效。例如，servlet-api，其在編譯和測試時需要使用，但在運行時由於容器已經提供，所以不需要mvn重新的引入一遍。
runtime=運行時。例如，JDBC驅動實現，類的編譯只需JDK提供的JDBC接口即可，在真正執行測試或運行時才需實現上述接口的具體JDBC驅動。
system=// 這個可以不用理解。
import=導入。
<optional>，可選依賴。例如，A->B，B->C（optional=true），那么A將對C不形成傳遞依賴。
<exclusions>，排除依賴。例如，A->B, B->C(1.0-SNAPSHOT)，而我實際想用C2.0，那么就需要在B中將C給排除出去。
對於同一模塊的jar包，可以在pom中通過統一變量進行定義
聲明<properties><springframework.version>2.5.6</…>
引用<version>${springframework.version}</…>
傳遞依賴（->表示依賴）：
A->B，而實際上，B->C，那么A對B是直接依賴，對C是傳遞依賴。其“能見度”如下表所示。第一列為A->B，對一行為B->C，表格中內容為，A->C。
| compile | test | provided | runtime | |
| compile | compile | no | no | runtime |
| test | test | no | no | test |
| provided | provided | no | provided | provided |
| runtime | runtime | no | no | runtime |
依賴調解：
A->B->C->X(1.0)
A->D->X(2.0)
那么，按路徑最短者生效（即X2.0）.
A->B->Y(1.0)
A->C->Y(2.0)
那么，mvn2.0.8及之前版本，順序不確定。mvn2.0.9以后，第一聲明者優先。
如何查看依賴：
一個事實：mvn會自動解析所有項目的直接依賴和傳遞性依賴，並且根據一定規則正確判斷每個依賴的范圍，對於一些依賴沖突，也能進行調節，以確保任何一個構件只有唯一的版本在依賴中存在。在這些工作之后，最后得到的那些依賴被稱為已解析依賴（Resolved Dependency）。
一個命令：mvn dependency:list
一個命令：mvn dependency:tree
一個命令：mvn dependency:analyze
==================以下為進階===================
生命周期：
public abstract class AbstractBuild(){
public void build(){
initialize(); // 初始化工作
compile(); // 編譯
test(); // 測試
package(); // 打包
integrationTest(); // 集成測試
deploy(); // 部署
}
}
這里只是個示意，以說明maven存在的價值、意義和定位。其中的每個步驟，都可以用插件來做。mvn也為我們設置了默認的插件，不過如果想進行個性化的定制，可以自己選擇plugin，或者自己寫plugin。
1）以下三個生命周期，相互獨立，且每個生命周期的每個步驟，均可單獨調用（但假如調步驟3的時候，其前的步驟1、2也是會執行的）。
2）注意，在命令行執行mvn命令，本身就是在調用mvn的生命周期哦，可愛吧，呵呵。
clean生命周期
pre-clean
clean
post-clean
default生命周期（從上到下，從左至右的看哦）
| validate |
generate-sources |
generate-test-sources |
prepare-package |
pre-interation-test |
| initialize |
process-sources（注1） |
process-test-sources |
package（注4） |
integration-test |
| generate-resources |
generate-test-resources |
verify |
||
| process-resources |
process-test-resources |
install（注5） |
||
| compile（注2） |
test-compile |
deploy（注6） |
||
| process-classes |
process-test-classes |
|||
| test（注3） |
注1：一般來說，對src/main/resources目錄的內容進行變量替換等工作后，復制到項目輸出的主classpath目錄當中去。
注2：一般來說，是編譯src/main/java目錄下的java文件至項目輸出的主classpath目錄當中去。
注3：使用單元測試框架運行測試，測試代碼不會被打包或部署。
注4：將編譯好的代碼，打包成可發布的格式，如jar。
注5：將包安裝到mvn本地倉庫，供本地其他mvn項目使用。
注6：將包復制到遠程倉庫。
site生命周期
暫略去不談。
認識插件：
1）在pom中，可自定義插件，並將其綁進生命周期中去。有些插件自己也會有默認的生命周期的，取決於插件自身實現。根據功能，也可以一個插件綁到N個階段中去。
2）在pom中，可對插件進行全局配置，例如maven-compiler-plugin默認都用JDK 1.5進行。
3）。。。差不多了，先寫到這里。