您好,登錄后才能下訂單哦!
本篇內容介紹了“maven怎么安裝”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
Maven是一個項目管理和綜合工具。 Maven提供了開發人員構建一個完整的生命周期框架。開發者團隊可以自動完成項目的基礎工具建設, Maven使用標準的目錄結構和默認構建生命周期。
在多個開發者團隊環境時, Maven可以設置按標準在非常短的時間里完成配置工作。 由于大部分項目的設置都很簡單, 并且可重復使用, Maven讓開發人員的工作更輕松, 同時創建報表, 檢查, 構建和測試自動化設置。
用過GitHub的同學看到這里應該感覺似曾相識,對,Maven和git的作用很相似,都是為了方便項目的創建與管理。
概括地說, Maven簡化和標準化項目建設過程。 處理編譯, 分配, 文檔, 團隊協作和其他任務的無縫連接。 Maven增加可重用性并負責建立相關的任務。
Maven設計之初, 是為了簡化Jakarta Turbine項目的建設。 在幾個項目, 每個項目包含了不同的Ant構建文件。 JAR檢查到CVS。 Apache組織開發Maven可以建立多個項目, 發布項目信息, 項目部署, 在幾個項目中JAR文件提供團隊合作和幫助。
Maven的經歷了Maven-> Maven2 -> Maven3的發展。
Maven之前我們經常使用Ant來進行Java項目的構建, 然后Ant僅是一個構建工具, 它并未對項目的中的工程依賴以及項目本身進行管理, 并且Ant作為構建工具未能消除軟件構建的重復性, 因為不同的項目需要編寫對應的Ant任務。
Maven作為后來者, 繼承了Ant的項目構建功能, 并且提供了依賴關系, 項目管理的功能, 因此它是一個項目管理和綜合工具, 其核心的依賴管理, 項目信息管理, 中央倉庫, 約定大于配置的核心功能使得Maven成為當前Java項目構建和管理工具的標準選擇。
學習Maven的理由是非常多:
主流IDE(Eclipse,IDEA,Netbean) 夠內置了Maven
SpringFramework已經不再提供jar的下載, 直接通過Maven進行依賴下載。
在github, 開源社區幾乎所有流行的Java項目都是通過Maven進行構建和管理的。
Maven作為一個構建工具,不僅能幫我們自動化構建,還能夠抽象構建過程,提供構建任務實現;它跨平臺,對外提供了一致的操作接口,這一切足以使它成為優秀的、流行的構建工具。
Maven不僅是構建工具,還是一個依賴管理工具和項目管理工具,它提供了中央倉庫,能幫我自動下載構件。
一:因為本人是window系統,所以這里只介紹window下如何安裝,在安裝Maven之前,先確認已經安裝了JDK.
二:接著去
Maven官網下載界面下載想要的版本解壓到你想要的目錄就行
三:最后設置一下環境變量,將Maven安裝配置到操作系統環境中,主要就是配置M2_HOME 和PATH兩項,如圖
都搞定后,驗證一下,打開doc輸入 mvn -v如何得到下面信息就說明配置成功了
bin目錄:
該目錄包含了mvn運行的腳本,這些腳本用來配置java命令,準備好classpath和相關的Java系統屬性,然后執行Java命令。
boot目錄:
該目錄只包含一個文件,該文件為plexus-classworlds-2.5.2.jar。plexus-classworlds是一個類加載器框架,相對于默認的java類加載器,它提供了更加豐富的語法以方便配置,Maven使用該框架加載自己的類庫。
conf目錄:
該目錄包含了一個非常重要的文件settings.xml。直接修改該文件,就能在機器上全局地定制Maven的行為,一般情況下,我們更偏向于復制該文件至~/.m2/目錄下(~表示用戶目錄),然后修改該文件,在用戶范圍定制Maven的行為。
lib目錄:
該目錄包含了所有Maven運行時需要的Java類庫,Maven本身是分模塊開發的,因此用戶能看到諸如maven-core-3.0.jar、maven-model-3.0.jar之類的文件,此外這里還包含一些Maven用到的第三方依賴如commons-cli-1.2.jar、commons-lang-2.6.jar等等。
mvn clean:表示運行清理操作(會默認把target文件夾中的數據清理)。 mvn clean compile:表示先運行清理之后運行編譯,會將代碼編譯到target文件夾中。 mvn clean test:運行清理和測試。 mvn clean package:運行清理和打包。 mvn clean install:運行清理和安裝,會將打好的包安裝到本地倉庫中,以便其他的項目可以調用。 mvn clean deploy:運行清理和發布(發布到私服上面)。
上面的命令大部分都是連寫的,大家也可以拆分分別執行,這是活的,看個人喜好以及使用需求,Eclipse Run as對maven項目會提供常用的命令。
<?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.tengj</groupId> <artifactId>springBootDemo1</artifactId> <version>0.0.1-SNAPSHOT</version> <name>springBootDemo1</name> </project>
代碼的第一行是XML頭,指定了該xml文檔的版本和編碼方式。
project是所有pom.xml的根元素,它還聲明了一些POM相關的命名空間及xsd元素。
根元素下的第一個子元素modelVersion指定了當前的POM模型的版本,對于Maven3來說,它只能是4.0.0
代碼中最重要是包含了groupId,artifactId和version了。這三個元素定義了一個項目基本的坐標,在Maven的世界,任何的jar、pom或者jar都是以基于這些基本的坐標進行區分的。
groupId定義了項目屬于哪個組,隨意命名,比如谷歌公司的myapp項目,就取名為 com.google.myapp
artifactId定義了當前Maven項目在組中唯一的ID,比如定義hello-world。
version指定了項目當前的版本0.0.1-SNAPSHOT,SNAPSHOT意為快照,說明該項目還處于開發中,是不穩定的。
name元素生命了一個對于用戶更為友好的項目名稱,雖然這不是必須的,但還是推薦為每個POM聲明name,以方便信息交流
<project> ... <dependencies> <dependency> <groupId>實際項目</groupId> <artifactId>模塊</artifactId> <version>版本</version> <type>依賴類型</type> <scope>依賴范圍</scope> <optional>依賴是否可選</optional> <!—主要用于排除傳遞性依賴--> <exclusions> <exclusion> <groupId>…</groupId> <artifactId>…</artifactId> </exclusion> </exclusions> </dependency> <dependencies> ... </project>
根元素project下的dependencies可以包含一個或者多個dependency元素,以聲明一個或者多個項目依賴。每個依賴可以包含的元素有:
grounpId、artifactId和version:以來的基本坐標,對于任何一個依賴來說,基本坐標是最重要的,Maven根據坐標才能找到需要的依賴。
type:依賴的類型,對于項目坐標定義的packaging。大部分情況下,該元素不必聲明,其默認值為jar
scope:依賴的范圍
optional:標記依賴是否可選
exclusions:用來排除傳遞性依賴
依賴范圍就是用來控制依賴和三種classpath(編譯classpath,測試classpath、運行classpath)的關系,Maven有如下幾種依賴范圍:
compile:編譯依賴范圍。如果沒有指定,就會默認使用該依賴范圍。使用此依賴范圍的Maven依賴,對于編譯、測試、運行三種classpath都有效。典型的例子是spring-code,在編譯、測試和運行的時候都需要使用該依賴。
test: 測試依賴范圍。使用次依賴范圍的Maven依賴,只對于測試classpath有效,在編譯主代碼或者運行項目的使用時將無法使用此依賴。典型的例子是Jnuit,它只有在編譯測試代碼及運行測試的時候才需要。
provided:已提供依賴范圍。使用此依賴范圍的Maven依賴,對于編譯和測試classpath有效,但在運行時候無效。典型的例子是servlet-api,編譯和測試項目的時候需要該依賴,但在運行項目的時候,由于容器以及提供,就不需要Maven重復地引入一遍。
runtime:運行時依賴范圍。使用此依賴范圍的Maven依賴,對于測試和運行classpath有效,但在編譯主代碼時無效。典型的例子是JDBC驅動實現,項目主代碼的編譯只需要JDK提供的JDBC接口,只有在執行測試或者運行項目的時候才需要實現上述接口的具體JDBC驅動。
system:系統依賴范圍。該依賴與三種classpath的關系,和provided依賴范圍完全一致,但是,使用system范圍的依賴時必須通過systemPath元素顯示地指定依賴文件的路徑。由于此類依賴不是通過Maven倉庫解析的,而且往往與本機系統綁定,可能構成構建的不可移植,因此應該謹慎使用。systemPath元素可以引用環境變量,如:
<dependency> <groupId>javax.sql</groupId> <artifactId>jdbc-stdext</artifactId> <Version>2.0</Version> <scope>system</scope> <systemPath>${java.home}/lib/rt.jar</systemPath> </dependency>
import:導入依賴范圍。該依賴范圍不會對三種classpath產生實際的影響。
上述除import以外的各種依賴范圍與三種classpath的關系如下:
比如一個account-email項目為例,account-email有一個compile范圍的spring-code依賴,spring-code有一個compile范圍的commons-logging依賴,那么commons-logging就會成為account-email的compile的范圍依賴,commons-logging是account-email的一個傳遞性依賴
有了傳遞性依賴機制,在使用Spring Framework的時候就不用去考慮它依賴了什么,也不用擔心引入多余的依賴。Maven會解析各個直接依賴的POM,將那些必要的間接依賴,以傳遞性依賴的形式引入到當前的項目中。
假設A依賴于B,B依賴于C,我們說A對于B是第一直接依賴,B對于C是第二直接依賴,A對于C是傳遞性依賴。第一直接依賴和第二直接依賴的范圍決定了傳遞性依賴的范圍,如下圖所示,最左邊一行表示第一直接依賴范圍,最上面一行表示第二直接依賴范圍,中間的交叉單元格則表示傳遞依賴范圍。
從上圖中,我們可以發現這樣的規律:
當第二直接依賴的范圍是compile的時候,傳遞性依賴的范圍與第一直接依賴的范圍一致;
當第二直接依賴的范圍是test的時候,依賴不會得以傳遞;
當第二直接依賴的范圍是provided的時候,只傳遞第一直接依賴范圍也為provided的依賴,切傳遞依賴的范圍同樣為provided;
當第二直接依賴的范圍是runtime的時候,傳遞性依賴的范圍與第一直接依賴的范圍一致,但compile列外,此時傳遞性依賴范圍為runtime.
Java生態體系中有三大構建工具:Ant、Maven和Gradle。其中,Ant是由Apache軟件基金會維護;Maven這個單詞來自于意第緒語(猶太語),意為知識的積累,最初在Jakata Turbine項目中用來簡化構建過程;Gradle是一個基于Apache Ant和Apache Maven概念的項目自動化構建開源工具,它使用一種基于Groovy的特定領域語言(DSL)來聲明項目設置,拋棄了基于XML的各種繁瑣配置。
經過幾年的發展,Ant幾乎銷聲匿跡,而Maven由于較為不靈活的配置也漸漸被遺忘,而由于Gradle是基于Ant和Maven的一個優化版本,變得如日中天。
Maven的主要功能主要分為依賴管理系統、多模塊構建、一致的項目結構、一致的構建模型和插件機制。這里通過這五個方面介紹兩者的不同:
在Maven的管理體系中,用GroupID、ArtifactID和Version組成的Coordination唯一標識一個依賴項。任何基于Maven構建的項目自身也必須定義這三項屬性,生成的包可以是Jar包,也可以是War包或Ear包。
一個典型的引用如下:
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> spring-boot-starter-data-jpa </dependency> <dependency> <groupId>org.springframework.boot</groupId> spring-boot-starter-thymeleaf </dependency> <dependency> <groupId>org.springframework.boot</groupId> spring-boot-starter-test <scope>test</scope> </dependency> </dependencies>
這里 GroupID類似于C#中的namespace或者Java中的package,而ArtifactID相當于Class,Version相當于不同版本,如果Version忽略掉,將選擇最新的版本鏈接。
同時,存儲這些組件的倉庫有遠程倉庫和本地倉庫之分,遠程倉庫可以是使用世界公用的central倉庫,也可以使用Apache Nexus自建的私有倉庫;本地倉庫則在本地計算機上。通過Maven安裝目錄下的settings.xml文件可以配置本地倉庫的路徑,以及采用的遠程倉庫地址。Gradle在設計時沿用了Maven這種依賴管理體系,同時也引入了改進,讓依賴變得更加簡潔:
dependencies { // This dependency is exported to consumers, that is to say found on their compile classpath. api 'org.apache.commons:commons-math4:3.6.1' // This dependency is used internally, and not exposed to consumers on their own compile classpath. implementation 'com.google.guava:guava:23.0' // Use JUnit test framework testImplementation 'junit:junit:4.12' compile 'org.hibernate:hibernate-core:3.6.7.Final' testCompile ‘junit:junit:4.+' }
另外,Maven和Gradle對依賴項的審視也有所不同。在Maven中,一個依賴項有6種scope,分別是compile、provided、runtime、test、system、import。其中compile為默認。而gradle將其簡化為4種,compile、runtime、testCompile、testRuntime。如上述代碼“testCompile ‘junit:junit:4.+’”,在Gradle中支持動態的版本依賴,在版本號后面使用+號可以實現動態的版本管理。在解決依賴沖突方面Gradle的實現機制更加明確,兩者都采用的是傳遞性依賴,而如果多個依賴項指向同一個依賴項的不同版本時可能會引起依賴沖突,Maven處理起來較為繁瑣,而Gradle先天具有比較明確的策略。
在面向服務的架構中,通常將一個項目分解為多個模塊。在Maven中需要定義parent POM(Project Object Model)作為一組module的通用配置模型,在POM文件中可以使用
Gradle也支持多模塊構建,在parent的build.gradle中可以使用allprojects和subprojects代碼塊分別定義應用于所有項目或子項目中的配置。對于子模塊中的定義放置在settings.gradle文件中,每一個模塊代表project的對象實例,在parent的build.gradle中通過allproject或subprojects對這些對象進行操作,相比Maven更顯靈活。
allprojects { task nice << { task -> println "I'm $task.project.name" } }
執行命令gradle -q nice會依次打印出各模塊的項目名稱。
Maven指定了一套項目目錄結構作為標準的java項目結構,Gradle也沿用了這一標準的目錄結構。如果在Gradle項目中使用了Maven項目結構的話,在Gradle中無需進行多余的配置,只需在文件中包括apply plugin:’java’,系統會自動識別source、resource、test source、test resource等相應資源。
同時,Gradle作為JVM上的構建工具,也支持Groovy、Scala等源代碼的構建,同樣功能Maven通過一些插件也能達到目的,但配置方面Gradle更靈活。
為了解決Ant中對項目構建缺乏標準化的問題,Maven設置了標準的項目周期,構建周期:驗證、初始化、生成原始數據、處理原始數據、生成資源、處理資源、編譯、處理類、生成測試原始數據、處理測試原始數據、生成測試資源、處理測試資源、測試編譯、處理測試類、測試、預定義包、生成包文件、預集成測試、集成測試、后集成測試、核實、安裝、部署。但這種構建周期也是Maven應用的劣勢。因為Maven將項目的構建周期限制過嚴,無法在構建周期中添加新的階段,只能將插件綁定到已有的階段上。而Gradle在構建模型上非常靈活,可以創建一個task,并隨時通過depends建立與已有task的依賴關系。
兩者都采用了插件機制,Maven是基于XML進行配置,而在Gradle中更加靈活。
“maven怎么安裝”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。