Maven從入門到放棄

推薦閱讀(點擊便可跳轉閱讀)

1. SpringBoot內容聚合

2. 面試題內容聚合

3. 設計模式內容聚合

4. Mybatis內容聚合

5. 多線程內容聚合

1.maven是什麼？

maven是Apache下的一個純java開發的一個開源項目，它是一款可以抽象構建過程，而且提供依賴管理，中央倉庫，自動下載構建等功能的項目構建工具。

2.爲何要使用maven工具構建項目？

假如咱們在開發兩個Java項目，暫時稱之爲A,B，這兩個項目中對於一些特殊功能會有互相依賴的狀況下，該如何作二者之間較好的關聯呢？是打算在A,B兩邊共用一套代碼進行關聯嗎？( 這樣的作法會很是難以進行後期的維護 )

若是咱們將共用的代碼打包成jar引入項目中使用的話，那麼後期進行代碼更新的話是否又要對全部引入的jar進行更新呢？這樣的作法彷佛很是繁瑣。

回想起之前作開發的時候，因爲maven技術尚未出現，使用ssh框架進行開發的時候，全部的jar都須要人爲的進行統一導入和維護，致使後期的維護難度極高。

而maven正是能夠解決以上所說的這些問題。

3.maven會如何進行jar的管理呢？

在maven這款工具裏面，有一個特別的概念叫作座標。這個座標可不是咱們數學裏面說的那個座標，可是在設定上確實和數學的座標有一點相似，就是每一個座標都會擁有屬於它本身的惟一標識。在maven裏面也不例外：

<dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>1.2.47</version>
        </dependency>複製代碼

例如上邊的這段座標信息，groupId 一般會用於標識該jar所屬的實際項目，因爲一般一個項目可能會劃分爲了多個模塊，所以artifactId 則是對於該項目的某個模塊進行了一個明確的標識。version元素更多的是定義了該構件的真實版本。一般咱們會稱呼這一段 dependency 爲依賴。

對於依賴的讀取還有一個叫作scope的配置

scope的分類	講解
compile	默認狀況下就是compile類型， 意味着該依賴既要參與編譯又要參與後期的測試等環節
test	表示該依賴僅僅參加和測試有關的工做
provided	能夠參與編譯，測試，運行等週期， 可是在打包的時候會進行exclude的相應操做， 其餘方面和compile差別不大
runntime	在編譯環節不會參與進來，我的感受和compile差別不大
system	一般是指不從倉庫讀取依賴，而是經過本地路徑來讀取依賴， 所以常與systemPath標籤結合使用

固然若是對於每一個依賴咱們都進行相應單獨的version設置，那麼管理起來會有些繁瑣，所以可使用或者標籤進行統一的管理，例以下方的這兩組案例：

基於parent的依賴管理：

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.4.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>複製代碼

基於properties的依賴管理，在properties裏面咱們能夠進行整個項目的統一字符集編碼管理或者對於一些依賴jar包統一版本號的管理：

<properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
        <lombok.version>1.16.6</lombok.version>
        <aspectj.version>1.8.11</aspectj.version>
        <common.version>3.4</common.version>
        <codec.version>1.10</codec.version>
        <swagger2.version>2.7.0</swagger2.version>
        <mybatis.version>3.3.0</mybatis.version>
        <mybatis-spring-boot.version>1.3.1</mybatis-spring-boot.version>
        <pagehelper.version>1.2.3</pagehelper.version>
        <springfox-swagger-ui.version>2.7.0</springfox-swagger-ui.version>
        <mysql.version>5.1.6</mysql.version>
        <mongodb.version>3.2.2</mongodb.version>
    </properties>複製代碼

4.maven的倉庫

那麼當咱們將相應的依賴導入到了工程裏面以後，又會發生什麼事情了呢？

maven的內部會有一個從網上邊下載依賴的功能，咱們一般稱這個擁有依賴jar的平臺爲倉庫。

在maven裏面倉庫有分爲多種：本地倉庫，第三方倉庫，中央倉庫

一般被下載下來的jar會存在開發者電腦上的本地倉庫，這個默認的地址是在 $user.home/.m2/repository目錄底下：

這裏面存儲了許多本身曾經下載過的jar，這樣就能夠避免往後再次使用到相同jar時二次請求中央倉庫了。

中央倉庫是指maven官方本身維護的一個遠程公用倉庫：

http://repo1.maven.org/maven2 在這裏面提供了豐富的jar包供開發人員進行下載使用。有時候咱們在開發中會碰見下載jar包網速過慢的狀況，這個時候能夠嘗試將mirrors配置修改成訪問阿里雲鏡像的配置：

<mirror>
    <id>alimaven</id>
     <name>aliyun maven</name>
     <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
     <mirrorOf>central</mirrorOf>
</mirror> 複製代碼

第三方倉庫一般是指公司本身內部搭建的公共類庫站點，只提供給公司內部共享服務所使用，一般都是搭建在局域網內部使用，並且對於內部私服的鏈接，一般公司都會有相關的帳號密碼進行控制。

Nexus就是一款較爲強大的Maven倉庫管理工具，它極大地簡化了本身內部倉庫的維護和外部倉庫的訪問。利用Nexus你能夠只在一個地方就可以徹底控制訪問 和部署在你所維護倉庫中的每一個Artifact。

Nexus是一套「開箱即用」的系統不須要數據庫，它使用文件系統加Lucene來組織數據。Nexus 使用ExtJS來開發界面，利用Restlet來提供完整的REST APIs，經過m2eclipse與Eclipse集成使用。Nexus支持WebDAV與LDAP安全身份認證。

除了Nexus之外，還有挺多知名的倉庫管理工具，例如說JFrog Artifactory

5.maven工程的項目結構是如何的呢？

在idea編譯器裏面，對於maven工程的建立時候，默認的結構一般都是以下所示：

在開發的時候，一般代碼編寫都是在main文件夾底下進行，而若是須要編寫相應的測試代碼則在test目錄底下進行，java目錄下通常是放置咱們的代碼內容，resources目錄底下更多的是存放一些咱們的配置文件，例如說xml，yml，properties這類型的文件內容。

固然若是是建立maven-web結構的工程的話，能夠在創建maven工程的時候選擇相應的構建模板：

項目結構以下所示：（可能idea版本不一樣，最終的成效截圖會有所出入）

固然，如今的項目大多都是基於父子工程的偏多，maven裏面也支持這種工程的搭建，一般咱們能夠事先構建好一個父工程結構，而後再在父工程的基礎上邊構建相應的module工程。例以下邊的工程截圖：

6.maven的經常使用命令和生命週期

其實maven它自己是具備三套獨立的生命週期的，這三套的生命週期分別是clean，default，site，分別有着不一樣的職責：清理，構建，創建站點

maven的三套生命週期之間實質上是須要互相依賴的，一般都是後者依賴於前者的關係，以clean生命週期爲例，它包含的階段有pre-clean、clean和post-clean。

當用戶調用pre-clean的時候，只有pre-clean階段得以執行；當用戶調用clean的時候，pre-clean和clean階段會得以順序執行；當用戶調用post-clean的時候，pre-clean、clean和post-clean會得以順序執行。

maven之因此將整個項目的階段劃分得如此細緻，我我的的觀點是這種細粒度的劃分更加地利於工程構建過程當中的排查錯誤，不一樣的環節由不一樣的插件來負責這一模塊，當拋出了異常報錯，咱們就只須要對該環節進行分析，例如編譯出錯，打包出錯等。

maven自身提供了很是多的命令供咱們使用，下邊列舉了咱們經常使用的命令基本以下：

• mvn archetype:create ：建立 Maven 項目

• mvn compile ：編譯源代碼

• mvn test-compile ：編譯測試代碼

• mvn test ： 運行應用程序中的單元測試

• mvn site ： 生成項目相關信息的網站

• mvn clean ：清除目標目錄中的生成結果

• mvn package ： 依據項目生成 jar 文件

• mvn install ：在本地 Repository 中安裝 jar

7.經過profile文件來指定特定的編譯環境

在實際的項目開發過程當中，咱們一般會須要結合實際的應用場合切換不一樣的運行環境（dev，test，pre，pro）,在不一樣的環境中咱們一般須要讀取不一樣的配置文件，例如不一樣的數據源配置，端口號配置等。

若是每次切換環境的時候都要開發人員進行相關的手動修改配置的方式來進行的話，那麼實際的工做效率會顯得較低，不妨能夠試試使用pom裏面提供的profile配置：

<profiles>
    <profile>
        <!-- 本地開發環境 -->
        <id>dev</id>
        <properties>
            <profiles.active>dev</profiles.active>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <profile>
        <!-- 測試環境 -->
        <id>test</id>
        <properties>
            <profiles.active>test</profiles.active>
        </properties>
    </profile>
    <profile>
        <!-- 生產環境 -->
        <id>pro</id>
        <properties>
            <profiles.active>pro</profiles.active>
        </properties>
    </profile>
</profiles>複製代碼

在pom文件裏面配置以上相應的profile內容以後，在進行工程打包的時候默認經過mvn clean package -Pdev（對應profile文件的id）的方式來判斷不一樣環境下的讀取方式。

這樣咱們就能夠更加專心的進行代碼開發工做，基於這種思路，咱們能夠經過編寫相應的腳原本實現不一樣環境下自動化打包的功能。