一、maven 优势
1 、约定优于配置
2 、简单
3、测试支持
4、构建简单
5、插件丰富
二、下载
- 地址:https://maven.apache.org/download.cgi
- 安装
- 超级pom的位置,在maven-model-builder-3.3.9.jar/org/apache/maven/model中的pom.xml.maven的默认结构在超级pom中定义。
- 配置 maven_home
- windows path
- Linux .bash_profile
- MVEN_OPTS
三、配置setting文件
setting.xml 标签讲解
1.<localRepository>D:\maven\repository</localRepository> 本地仓库位置
2. <pluginGroups> <pluginGroup></pluginGroup></pluginGrops>插件组
3.<proxies><proxy></proxy></proxies>
在特殊的网络策略环境下,可能要需要开发人员通过代理服务器来访问互联网。此时就需要给Maven配置代理服务来访问仓库、更新相关资源。
<proxies>
<proxy>
<id>myProxy</id>
<active>true</active>
<protocol>http</protocol>
<host>123.123.123.123</host>
<port>8080</port>
<username>XXXXX</username>
<password>XXXXX</password>
<nonProxyHosts>*.XXX.com|XXX.org</nonProxyHosts>
</proxy>
</proxies>
在<settings>标签中添加如上代码,说明如下:
(1)proxies中可以配置多个proxy,但是默认第一个proxy生效。
(2)active中的TRUE表示该代理目前生效状态。
(3)http协议、主机地址、端口不在赘述。
(4)用户名密码按需配置即可。
(5)nonProxyHost表示不需要代理访问的地址。中间的竖线分隔多个地址,此处可以使用星号作为通配符号。
4.<servers><server></server></servers>
配置服务端的一些设置。一些设置如安全证书不应该和pom.xml一起分发。这种类型的信息应该存在于构建服务器上的settings.xml文件中。
<!--服务器元素包含配置服务器时需要的信息 -->
<server>
<!--这是server的id(注意不是用户登陆的id),该id与distributionManagement中repository元素的id相匹配。 -->
<id>server001</id>
<!--鉴权用户名。鉴权用户名和鉴权密码表示服务器认证所需要的登录名和密码。 -->
<username>my_login</username>
<!--鉴权密码 。鉴权用户名和鉴权密码表示服务器认证所需要的登录名和密码。 -->
<password>my_password</password>
<!--鉴权时使用的私钥位置。和前两个元素类似,私钥位置和私钥密码指定了一个私钥的路径(默认是/home/hudson/.ssh/id_dsa)以及如果需要的话,一个密钥 -->
<!--将来passphrase和password元素可能会被提取到外部,但目前它们必须在settings.xml文件以纯文本的形式声明。 -->
<privateKey>${usr.home}/.ssh/id_dsa</privateKey>
<!--鉴权时使用的私钥密码。 -->
<passphrase>some_passphrase</passphrase>
<!--文件被创建时的权限。如果在部署的时候会创建一个仓库文件或者目录,这时候就可以使用权限(permission)。-->
<!--这两个元素合法的值是一个三位数字,其对应了unix文件系统的权限,如664,或者775。 -->
<filePermissions>664</filePermissions>
<!--目录被创建时的权限。 -->
<directoryPermissions>775</directoryPermissions>
<!--传输层额外的配置项 -->
<configuration></configuration>
</server>
5.<mirrors><mirror></mirror></mirrors>
mirror可以拦截对远程仓库的请求 , 改变对目标仓库的下载地址。 mirror就是镜像,主要提供一个方便地切换远程仓库地址的途径。比如,上班的时候在公司,用电信的网络,连的是电信的仓库。回到家后,是网通的网络,我想连网通的仓库,就可以通过mirror配置,统一把我工程仓库里的地址都改成联通的,而不必到工程配置地址里一个一个地改地址。
需要注意的是,由于镜像仓库完全屏蔽了被镜像仓库,当镜像仓库不稳定或者停止服务的时候,Maven仍将无法访问被镜像仓库,因而将无法下载构件。
maven的conf/setting.xml
<mirrors>
<!--国内阿里云提供的镜像,非常不错-->
<mirror>
<!--This sends everything else to /public -->
<id>aliyun_nexus</id>
<!--对所有仓库使用该镜像,除了一个名为maven_nexus_201的仓库除外-->
<!--这个名为maven_nexus_201的仓库可以在javamaven项目中配置一个repository-->
<mirrorOf>*,!maven_nexus_201</mirrorOf>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
</mirror>
</mirrors>
maven项目下的pom.xml配置一个远程仓库
<repositories>
<!-- 192.168.0.201远程仓库 -->
<repository>
<id>maven_nexus_201</id>
<name>maven_nexus_201</name>
<layout>default</layout>
<url>http://192.168.0.201:8081/nexus/content/groups/public/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
6.<profiles><profile></profile></profiles>
把pom.xml中<repositories>这部分配置到maven的setting.xml的节点<profiles>里。<profiles>里可以配置多个<profile>,<repositories>里也是可以配置多个<repository>。按照我自己的理解,每个<profile>就相当于<repositories>的<repository>。不同点在于:<repositories>里配置的多个<repository>都是有效的;而<profiles>里配置了多个<profile>,需要使用<activeProfiles>来进行激活,激活了哪个<profile>,哪个<profile>才生效。
setting.xml中profile的配置如下图:
四、新建一个Maven项目
1.项目结构
2.pom.xml
(1)groupId 组名 通常为公司域名反过来 例如:com.xxx
(2)artfactId 功能名 通常为项目名称
(3)version 版本号
(4)packaging 打包方式 默认是jar
(5)dependencyManagement
i:只能出现在父pom中
ii:统一版本号
iii:声明不会被子pom继承(子pom中用到再引)
(6)dependency
i.type默认是jar
ii scope
a)complie 编译(默认) 默认会打包 如spring-core
b)test 测试 不会打包 如junit包scope 要给成test
c)provided 编译 不会打包 如servlet
d)runtime 运行时有效,编译时不用 例如JDBC 驱动实现 会打包
e)system 本地的一些jar包 不在maven仓库中。自己写的jar包的引用方法:1.搭建私服,放到私服上去(推荐) 2.install到本地仓库 3.add到classPath中去 4.使用maven 的system(不推荐)
scope意义:1.依赖在什么阶段使用 2.会不会被打成jar包
f)依赖传递
假如有Maven项目A,项目A依赖B,项目B依赖C。那么我们可以说 A依赖C。也就是说,依赖的关系为:A—>B—>C。那么我们执行项目A时,会自动把B、C都下载导入到A项目的jar包文件夹中。 这就是依赖的传递性。
A–>B–>C。当前项目为A,A依赖于B,B依赖于C。知道B在A项目中的scope,那么怎么知道C在A中的scope呢?答案是:当C是test或者provided时,C直接被丢弃,A不依赖C;否则A依赖C,C的scope继承于B的scope。
下面是一张nexus画的图。
g)依赖的冲突与解决(依赖仲裁)
依赖冲突:一个项目A,通过不同依赖传递路径依赖于X,若在不同路径下传递过来的X版本不同,那么A应该导入哪个版本的X包呢?
冲突解决方案:
1:如果依赖路径的长度不同,则“短路优先”:
A—>B—>C—>D—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则A依赖于X(version 0.0.2)。
2:依赖路径长度相同情况下,则“先声明优先”:
A—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则在项目A的<depencies></depencies>中,E、F那个在先则A依赖哪条路径的X。
h)依赖传递排除(排除包)
如上,A—>B—>C。加入现在不想执行A时把C下载进来,那么我们可以用 <exclusions>标签。
<dependencies>
<dependency>
<groupId>B</groupId>
<artifactId>B</artifactId>
<version>0.0.1</version>
<exclusions>
<exclusion>
<!--被排除的依赖包坐标-->
<groupId>C</groupId>
<artifactId>C</artifactId>
<version>0.0.1</version>
</exclusion>
</exclusions>
</dependency>
</dependencies>
五、maven 的生命周期 lifeCycle/phase/goal
- A Build Lifecycle is Made Up of Phases
2.A build Phase is Made Up of Plugin Goals