您好,登錄后才能下訂單哦!
本篇內容主要講解“如何快速掌握Maven的核心概念”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“如何快速掌握Maven的核心概念”吧!
坐標
坐標的概念
能夠確定一個點在空間的位置的一個或一組數,叫做這個點的坐標。通常由這個點到垂直相交的若干條固定的直線的距離來表示 。這些直線叫做坐標軸。坐標軸的數目在平面上為2(x,y),在空間里為3(x,y,z)。
其實就是可以標識平面中或空間里唯一的一個點。
Maven中的坐標
Maven其中一個核心的作用就是管理項目的依賴,引入我們所需的各種jar包等。為了能自動化的解析任何一個Java構件,Maven必須將這些Jar包或者其他資源進行唯一標識,這是管理項目的依賴的基礎,也就是我們要說的坐標。包括我們自己開發的項目,也是要通過坐標進行唯一標識的,這樣才能才其它項目中進行依賴引用。
案例
依賴時候:比如下面我們依賴junit的jar包。
<!-- pom.xml中 --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency>
項目中定義我們的項目將打成jar或者war包。
<?xml version="1.0" encoding="UTF-8"?> <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/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.tian</groupId> <artifactId>maven-demo</artifactId> <version>1.0-SNAPSHOT</version> <!-- 默認是jar --> <packaging>jar</packaging> </project>
最后打出來的jar或war的形式的形式:
artifactid-version.jar artifactid-version.war
packaging 標簽默認是jar,所以通常我們在沒有指定打成jar包還是war的時候,最終打成的就是jar包。
Maven坐標的組成
「groupId」組織標識(包名)。定義當前Maven項目隸屬的實際項目。首先,Maven項目和實際項目不一定是一對一的關系。比如SpringFrameWork這一實際項目,其對應的Maven項目會有很多,如spring-core,spring-context等。這是由于Maven中模塊的概念,因此,一個實際項目往往會被劃分成很多模塊。其次,groupId不應該對應項目隸屬的組織或公司。原因很簡單,一個組織下會有很多實際項目,如果groupId只定義到組織級別,而后面我們會看到,artifactId只能定義Maven項目(模塊),那么實際項目這個層次將難以定義。最后,groupId的表示方式與Java包名的表達方式類似,通常與域名反向一一對應。上例中,groupId為junit,是不是感覺很特殊,這樣也是可以的,因為全世界就這么個junit,它也沒有很多分支。
「artifactId」項目名稱。該元素定義當前實際項目中的一個Maven項目(模塊),推薦的做法是使用實際項目名稱作為artifactId的前綴。比如上例中的junit,junit就是實際的項目名稱,方便而且直觀。在默認情況下,maven生成的構件,會以artifactId作為文件頭,如junit-3.8.1.jar,使用實際項目名稱作為前綴,就能方便的從本地倉庫找到某個項目的構件。
「version」項目的當前版本或者我們要依賴jar的版本。該元素定義了使用構件的版本,如上例中junit的版本是3.8.1,你也可以改為4.0表示使用4.0版本的junit。
「packaging」項目的打包方式,最為常見的jar和war兩種,默認是jar。定義Maven項目打包的方式,使用構件的什么包。首先,打包方式通常與所生成構件的文件擴展名對應,如上例中沒有packaging,則默認為jar包,最終的文件名為junit-3.8.1.jar。也可以打包成war等。
「classifier」 該元素用來幫助定義構建輸出的一些附件。附屬構件與主構件對應,如上例中的主構件為junit-3.8.1.jar,該項目可能還會通過一些插件生成如junit-3.8.1-javadoc.jar,junit-3.8.1-sources.jar, 這樣附屬構件也就擁有了自己唯一的坐標。
上述5個元素中,groupId、artifactId、version是必須定義的,packaging是可選的(默認為jar),而classfier是不能直接定義的,需要結合插件使用。
Maven為什么使用坐標呢?
Maven世界里擁有大量構建,我們需要找一個用來唯一標識一個構建的統一規范。
擁有了統一規范,就可以把查找工作交給機器。
maven依賴管理
依賴
依賴通常表現為:我需要你的東西,就像情侶之間相互依賴,夫妻之間相互依賴,人依賴于水,人依賴于糧食等。
在Maven中則表現為:項目中用到b.jar包的每個類,此時的項目就依賴b.jar。
復雜點關系就是多層依賴:a.jar包依賴b.jar包,還有可能b.jar包依賴c.jar。這種現象也可以稱之為依賴傳遞性。
我們的項目間接性的依賴了b.jar。
依賴配置
Maven中依賴配置案例如下:
<!--添加依賴配置--> <dependencies> <!--項目要使用到junit的jar包,所以在這里添加junit的jar包的依賴--> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.9</version> <scope>test</scope> </dependency> <!--項目要使用到Hello的jar包,所以在這里添加Hello的jar包的依賴--> <dependency> <groupId>com.tian.maven</groupId> <artifactId>user-service</artifactId> <version>0.0.1-SNAPSHOT</version> <scope>compile</scope><!-- 依賴范圍--> </dependency> </dependencies>
依賴范圍
所謂的依賴范圍就是指我們在什么需要依賴的jar。有的是在編譯的時候就需要,有的是測試的時候需要等。
依賴范圍scope有以下6種:
「compile」 默認編譯依賴范圍。對于編譯,測試,運行三種classpath都有效。即在編譯、測試和運行的時候都要使用該依賴jar包;
「test」測試依賴范圍。只對于測試classpath有效。而在編譯和運行項目時無法使用此類依賴,典型的是JUnit,它只用于編譯測試代碼和運行測試代碼的時候才需要;
「provided」已提供依賴范圍。對于編譯,測試的classpath都有效,但對于運行無效。因為由容器已經提供,例如servlet-api.jar,這個在編譯和測試的時候需要用到,但是在運行的時候,web容器已經提供了,就不需要maven幫忙引入了。
「runtime」運行時依賴范圍,使用此依賴范圍的maven依賴,對于編譯測試、運行測試和運行項目的classpath有效,但在編譯主代碼時無效,比如jdbc驅動實現,運行的時候才需要具體的jdbc驅動實現。
「system」系統依賴范圍,使用system范圍的依賴時必須通過systemPath元素顯示地指定依賴文件的路徑,不依賴Maven倉庫解析,所以可能會造成建構的不可移植(即就是在你的電腦上可能沒問題,但是到別人電腦上那就說不清楚了),有點類似provided ,注意這個system謹慎使用。
<systemPath>${java.home}/lib/rt.jar</systemPath>
「import」僅pom在本節中的類型依賴項上支持此作用域。它指示依賴關系將被指定的pom部分中的有效依賴關系列表替換。由于已替換它們,因此范圍為的依賴項import實際上不會參與限制依賴項的可傳遞性,在springboot和springcloud中用到的比較多。
以上六種范圍中,常用的有compile、test、runtime、provided 。
依賴范圍不僅可以控制與三種classpath的關系,還對傳遞性依賴產生影響,依賴關系圖如下:
「注意」預期這應該是運行時范圍,因此必須明確列出所有編譯依賴項。但是,如果您依賴的庫從另一個庫擴展了一個類,則兩者都必須在編譯時可用。因此,即使編譯時間相關性是可傳遞的,它們仍保留為編譯范圍。
Maven倉庫管理
Maven倉庫
用來統一存儲所有Maven共享構建的位置,說白了就是用來存放jar包的,我們本地每次編譯的時候沒有對應jar包是編譯通不過的,我們一個項目中是需要很多jar的依賴的,這時候就知道倉庫的重要性了。
Maven倉庫布局
根據Maven坐標定義每個構建在倉庫中唯一存儲路徑,大致為:
groupId/artifactId/version/artifactId-version.packaging
本地倉庫
在上一篇文章中,每個用戶只有一個本地倉庫,默認是在~/.m2/repository/,~代表的是用戶目錄 。為了便于管理,一般都會自己搞一目錄,專門用來存儲本地倉庫內容。這樣我們開發的時候,依賴那個jar就直接去我們的本地倉庫repository中去查找,如果沒有,我們會從中央倉庫中拉取。
中央倉庫
基本上保存了對外開發的所有jar包,Maven默認的遠程倉庫,(外國網站)URL地址:http://search.maven.org/ 。還有比如阿里的倉庫,我們在開發的時候,由于網絡原因,很多人都喜歡使用阿里的這個倉庫:http://maven.aliyun.com 。
這時候我們本地倉庫和中央倉庫的關系:
私服
大部分公司都會搭建私服,私服就是一種特殊的遠程倉庫,它是架設在局域網內的倉庫 。比如公司搭建局域網,公司也搞個倉庫,然后開發人員就直接使用公司搭建的私服就行了,這樣大大減少了網絡開銷以及開發成本(有時候外網訪問很慢,會浪費大家開發時間的)。
這樣開發人員每次需要每個jar包就直接從公司的私服里拉取,不需要使用外網去中央倉庫里拉取了。總之節約時間和節約網絡開始。并且有些企業還是不給外網的,這時候你就知道這個私服的重要性了。
增加了私服后,本地倉庫+私服+中央倉庫的關系圖:
面試中也頻繁被問:本地倉庫、私服以及中央倉庫是什么關系?
Maven生命周期
Maven的 生命周期:從我們的項目構建,一直到項目發布的這個過程。
每個階段的說明:
為了完成 default 生命周期,這些階段(包括其他未在上面羅列的生命周期階段)將被按順序地執行。
Maven 有以下三個標準的生命周期:
Clean Lifecycle 在進行真正的構建之前進行一些清理工作。
Default Lifecycle 構建的核心部分,編譯,測試,打包,部署等等。
Site Lifecycle 生成項目報告,站點,發布站點。
這三個標準它們是相互獨立的,你可以僅僅調用clean來清理工作目錄,僅僅調用site來生成站點。當然你也可以直接運行 mvn clean install site運行所有這三套生命周期。
運行任何一個階段的時候,它前面的所有階段都會被運行,這也就是為什么我們運行mvn install 的時候,代碼會被編譯,測試,打包。此外,Maven的插件機制是完全依賴Maven的生命周期的,因此理解生命周期至關重要。
Maven插件
Maven是不做具體事情的,只是規定了生命周期的各個階段和步驟,由集成到 Maven 中的插件完成。
Maven的核心僅僅定義了抽象的生命周期,具體的任務都是交由插件完成的。
每個插件都能實現多個功能,每個功能就是一個插件目標。
Maven的生命周期與插件目標相互綁定,以完成某個具體的構建任務, 例如compile就是插件maven-compiler-plugin的一個插件目標。
關于插件,這里就說個大概,后續會出一篇文章專門來說Maven插件。
排除不需要依賴
<dependency> <groupId>com.tian.maven</groupId> <artifactId>my-maven</artifactId> <version>1.0.0</version> <exclusions> <exclusion> <groupId>com.tian.maven</groupId> <artifactId>your-maven</artifactId> </exclusion> </exclusions> </dependency>
上面使用使用exclusions元素排除了my-maven->your-maven依賴的傳遞,也就是my-maven->your-maven不會被傳遞到當前項目中。
exclusions中可以有多個exclusion元素,可以排除一個或者多個依賴的傳遞,聲明exclusion時只需要寫上groupId、artifactId就可以了,version可以省略。
到此,相信大家對“如何快速掌握Maven的核心概念”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。