Maven是目前最流行的自动化构建工具,并不是作用域代码开发的任何一层,跟Git一样,对辅助编码没有作用,在开发环境中,一个大的项目往往需要很多的工程,一个项目不仅仅是一个工程。在这个时候,多个工程整合在一起,那么就需要使用Maven这种自动化构建工具。
①: 我们现在的开发,一个项目就是一个工程,如果项目非常庞大,就不再适合使用package来划分模块,最好的方式就是每个模块就是一个全新的工程,对于我们工作的划分协调和代码维护来说,借助Maven就可以将一个项目拆分成多个工程。
②:每做一个项目就要往lib目录下添加n多个jar包
③:所有的项目中jar包都需要手动添加到项目中,所以存在很多相同的jar包重复的存放在很多的项目中,造成项目的体积庞大。
④:jar包之间的依赖关系,我们很难确定。
⑤:我们一个正常的功能开发:编码—编译—打包—部署—测试,这5个环节,实际上真正需要人操作的就只有编码和测试,其他的都是程式化的操作,现在的Eclipse可以帮我们进行自动编译,但是不能完成自动打包及自动部署。
以上提出的5个问题,都是maven可以解决的问题。
构建的过程就是我们编写的Java代码,框架的配置文件,国际化等等其他的资源文件,jsp,图片等等作为原材料,去生产一个可以运行的项目的过程,这才叫做构建。
添加M2_HOME环境变量后,再添加到Path中。
4.查看Maven版本信息验证安装是否正确
打开cmd,输入mvn -v
至此为止,Maven安装就结束了。
下面来配置一下Maven核心程序
①:找到安装目录下的conf文件夹 下的setting.xml文件
②:配置本地仓库和远程仓库
<localRepository>F:/wbyq/maven/repositorylocalRepository> //本地仓库
<mirror>
<id>alimavenid>
<mirrorOf>centralmirrorOf>
<name>aliyun mavenname>
<url>https://maven.aliyun.com/nexus/content/groups/public/url>
mirror>
mirrors>
点击add添加,并apply
Global Settings是全局配置
现在eclipse中就添加好了Maven.
解释一下目录结构:
src/main/java: 以后我们主要写java程序的目录
src/main/resources: 配置文件的存放地址
src/test/java: 测试程序的目录(一般不用)
target: maven编译后的结果存放的目录
**pom.xml(重点)*依赖的配置文件
例:
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.0version>
<scope>testscope>
dependency>
dependencies>
大家注意到在依赖的配置中,除了所需要依赖jar包的坐标之外,还有一个scope设置,scope表示的是范围,这里指的就是依赖的范围,依赖的范围有几个可选值,常用的有三个:
那么对于compile范围和provided范围的依赖区别在哪里呢?
Compile和provided 范围的区别在于,Compile是参与部署的依赖jar包,而provided 范围是不参与部署的依赖的jar包。
我们可以创建一个Maven的web工程来测试一番。
依赖的有效性总结:
Test | Compile | provided | |
---|---|---|---|
主程序 | × | √ | √ |
测试程序 | √ | √ | √ |
参与部署 | × | √ | × |
在A工程中依赖b.jar,b.jar中依赖c.jar,如果A工程工程中对b.jar的依赖是compile范围,b.jar中依赖的c.jar也是compile范围,则b.jar会将依赖的c.jar传递给A工程。
Maven工程 | 依赖的范围 | 对A工程的可见性 | ||
---|---|---|---|---|
A | B | C | compile | √ |
D | test | × | ||
E | provided | × |
依赖的排除:
依赖的排除:当我们当前工程中依赖了B jar包,而B jar包又依赖了C jar包,如果依赖的方位是compile范围,这个时候C jar包就会被B jar包传递给当前工程,如果说依赖自动传递的jar包 c是一个不稳定版本的jar包,或者对当前的工程会产生影响,那么我们当前工程可以在依赖B jar包的时候将传递过来的C jar包排除
<dependency>
<groupId>com.wanbangee.mavengroupId>
<artifactId>HelloFriendartifactId>
<version>0.0.1-SNAPSHOTversion>
<type>jartype>
<scope>compilescope>
<exclusions>
<exclusion>
<groupId>com.wanbangee.mavengroupId>
<artifactId>HelloartifactId>
exclusion>
exclusions>
dependency>
5.依赖的原则:jar包冲突解决原则,在MakeFriends中依赖了HelloFriend,HelloFriend中依赖了Hello,并且将依赖的Hello传递给了MakeFriends,现在我们在MakeFriends中直接依赖Hello,这个时候有两个Hello,造成了冲突,那么MakeFriends中使用哪个Hello呢?
1) 路径最短者优先
2) 路径相同时,先声明者优先
<properties>
<wanbang.spring.version>5.1.5.RELEASEwanbang.spring.version>
properties>
<dependencies>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-coreartifactId>
<version>${wanbang.spring.version}version>
<scope>compilescope>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-beansartifactId>
<version>${wanbang.spring.version}version>
<scope>compilescope>
dependency>
<dependency>
<groupId>org.springframeworkgroupId>
<artifactId>spring-aopartifactId>
为什么需要继承呢?由于非compile范围的依赖不能在依赖链中传递,所以需要每个工程单独配置非compile范围的依赖,就比如我们junit依赖。如果现在各个工程的junit版本都需要是4.9,那么这个时候各个工程手动去修改无疑是不可取的,使用继承就可以将这样的依赖信息统一到父工程中进行统一管理。
①创建父工程,一般都使用Java工程,唯一需要注意的是打包方式为pom。
②在父工程中配置jar包的依赖
<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.0modelVersion>
<groupId>com.wanbangee.mavengroupId>
<artifactId>ParentartifactId>
<version>0.0.1-SNAPSHOTversion>
<packaging>pompackaging>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.9version>
<scope>testscope>
dependency>
dependencies>
dependencyManagement>
project>
③在子工程中引用父工程
<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.0modelVersion>
<artifactId>HelloartifactId>
<parent>
<groupId>com.wanbangee.mavengroupId>
<artifactId>ParentartifactId>
<version>0.0.1-SNAPSHOTversion>
<relativePath>../Parent/pom.xmlrelativePath>
parent>
<name>Helloname>
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
dependency>
dependencies>
project>
为什么需要聚合?将一个项目拆分成一个工程之后,需要手动逐个安装到仓库后才能够生效,修改后每个工程都需要单独的进行maven的各项操作。所有聚合之后,就可以对聚合的所有的工程统一的执行maven指令,比如打包,安装…
聚合的配置非常简单:
<modules>
<module>../Hellomodule>
<module>../HelloFriendmodule>
<module>../MakeFriendsmodule>
<module>../HelloWorldmodule>
<module>OurFriendmodule>
modules>
注意点:需要在pom打包方式的工程中配置聚合。