maven的概念-02
1.仓库
仓库分为两类:
1) 本地仓库 ->当前电脑上的maven仓库;
本地仓库的默认目录:
${user.home}/.m2/repository
如果想修改本地仓库目录:
打开 maven解压目录/conf下的setting.xml;
找到<localRepository>标签;解开注释;写入仓库目录;
<localRepository>D:\maven\repository</localRepository>
2) 远程仓库 ->局域网私服;
->中央仓库和为其分担压力的镜像;
添加远程仓库:
打开 maven解压目录/conf下的setting.xml;
找到<mirrors>标签;向里面添加一条<mirror>;
<mirror>
<id>nexus-public-snapshots</id>
<mirrorOf>public-snapshots</mirrorOf>
</mirror>
3)仓库中的文件:
maven插件;
自己开发的项目模块;
第三方jar包;
不管是什么样的jar包,都是按照坐标来建立目录结构的;所以可以通过统一的方式来查询或依赖;
2.依赖
依赖是maven中的关键部分,我们使用maven最主要就是使用它的依赖管理功能;
1)关于依赖
当A jar包用到了B jar包中的某些类时,A就对B产生了依赖;
在java工程中添加依赖的方式为:在pom.xml 文件的 <dependencys>标签下 ,添加一条<dependency>
例如:添加junit依赖:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<!-- 表示开发的时候引入,发布的时候不会加载此包 -->
<scope>test</scope>
</dependency>
依赖的格式是按目标jar包的坐标来的;
其中的<scope>标签里的内容表示依赖的范围;
2)关于依赖的范围
常用的依赖范围有三个:
compile ->对主程序和测试程序可见;也会参与项目的部署;最主要的依赖范围;
test ->只对测试程序可见,不参与部署;
也就是说,maven标准目录结构中的src/main/java里的程序不可以使用用该jar包里的内容;
只有src/test/java里的程序可以依赖test范围的jar包;
项目部署到服务器上时,test范围的jar包不会被部署;
例如junit;
provided ->对主程序和测试程序可见;不参与部署;例如;servelet-api;服务器中自带,不需要部署,但测试程序和主程序还必须依赖;
依赖有效性如图:
3)依赖的传递性:
如果A依赖B;
B依赖C;
A是否能使用C取决于B依赖C的范围是否是compile;
4)依赖的排除
如果当某个java工程依赖jar包A;
而 A依赖 B;
maven 将自动引入B;
这样会有一个问题:如果B不稳定,不想让B被自动引入;
可以在依赖A 时排除B;
配置方式:用<exclusions>标签
<dependency>
<groupId>com.liusir</groupId>
<artifactId>hello</artifactId>
<version>1.0</version>
<scope>compile</scop>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
5)统一化管理依赖jar包版本
对于同一个 框架的一组jar包,最好使用相同的版本;
为了方便升级框架,可以将jar包的版本信息统一提取出来;
具体操作:
1】 统一声明版本号:com.liusir.version是自定义标签
<properties>
<com.liusir.version>4.02<com.liusir.version>
</properties>
2】引用前面声明的版本号
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${com.liusir.version}</version>
</dependency>
3】其它用法
比如声明字符集;当然引用时和版本号的引用方式一样;
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
6)依赖的原则
路径最短者优先:
比如说,MakeFriend依赖HelloFriend;
HelloFriend依赖Hello;
HelloFriend和Hello中都依赖了log4j,由于依赖传递两个log4j都会传递到MakeFriend;
根据路径最短者优先,MakeFriend 会依赖 HelloFriend中的 log4j;
路径相同时先声明者优先;声明先后顺序是指dependency标签配置的先后顺序;
比如说,MakeFriend同时依赖HelloFriend 以及 OurFriend;
HelloFriend和OurFriends中都依赖log4j ;
而HelloFriend 对两个类的 依赖路径都是 1;
根据先声明者优先的原则,如果HelloFriend在MakeFriend的pom.xml中dependency先配置,MakeFriend就依赖HelloFriend的log4j ;
3.maven的生命周期
maven的生命周期定义了各个构建环节执行的顺序;
有了这个清单maven就可以自动化执行构建命令了;
maven有三个独立的生命周期:
clean lifecycle ->进行构建之前的一些清理工作;
default lifecycle ->构建的核心部分;编译、测试、打包、安装、部署等;
site lifecycle ->生成项目报告、站点、发布站点;
三个周期之间是相互独立的;
例如 :mvn clean 仅能用来清理;mvn site 用来生成站点;也可以 mvn clean install site 同时运行三套生命周期;
每套生命周期都由一组阶段组成;
平时输入命令时总对应于一个特定的阶段;
例如:mvn clean 对应clean周期里的clean阶段;clean周期里还有其它阶段;
1)clean周期
clean周期包含三个阶段:
①pre-clean 执行一些需要在clean之前完成的工作
②clean 移除所有上一次构建生成的文件
③post-clean 执行一些需要在clean之后立刻完成的工作
2)site 周期
①pre-site 执行一些需要在生成站点文档之前完成的工作
②site 生成项目的站点文档
③post-site 执行一些需要在生成站点文档之后完成的工作,并且为部署做准备
④site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是site阶段和site-deploy阶段,用以生成和发布Maven站点,这可是Maven相当强大的功能,Manager比较喜欢,文档及统计数据自动 生成,很好看。
3)default周期
Default生命周期是Maven生命周期中最重要的一个,绝大部分工作都发生在这个生命周期中。这里,只解释一些比较重要和常用的阶段:
validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件,至目标目录,准备打包。
compile 编译项目的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件,至目标测试目录。
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码,打包成可发布的格式,如JAR。
pre-integration-test
integration-test
post-integration-test
verify
install将包安装至本地仓库,以让其它项目依赖。
deploy将最终的包复制到远程的仓库,以让其它开发人员与项目共享或部署到服务器上运行。
4)生命周期与自动化构建
运行任何一个阶段时,它前面的所有阶段都会被执行;
例如:mvn package打包命名,不仅会打包,还会执行前面的 编译mvn compile、测试mvn test等;
这也是maven能自动执行构建过程的原因;
maven的插件机制是完全依赖maven的生命周期的;
4.插件和目标
maven 的核心仅定义了抽象的生命周期,具体任务都是插件完成的;
每个插件都能实现多个功能,每个功能就是一个插件目标;
maven的生命周期与插件目标相互绑定,以完成某个具体的构建任务;
例如:compile 是插件 maven-compiler-plugin 的一个目标;
test-compile 也是插件 maven-compiler-plugin 的一个目标;
pre-clean 是插件 maven-clean-plugin的一个目标;
eclipse中的maven插件:
eclipse中一般集成了maven插件;windows|preferences|maven 可找到maven设置;
其中重要的配置有:installtions和user settings
选 installtions 可设置maven 的位置;
user settings 指定 conf/settings.xml的位置,进而通过配置来获取本地仓库位置;
5.继承
因为依赖的传递规则中,只有compile范围的依赖可以传递;
有时候为了统一管理版本,其它范围的依赖也需要统一;比如junit经常是test范围;
这是可以利用继承机制;
例如:将junit依赖统一提取到父工程;在子工程中声明junit依赖时不指定版本,以父工程为主;
①创建Parent工程,打包方式为pom
②收集所有非compile范围的依赖信息,使用dependencyManagement标签统一管理
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
③在各个子工程中引用父工程
<parent>
<groupId>com.atguigu.maven</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 以当前文件为基准查找父工程中pom.xml文件的相对路径 -->
<relativePath>../Parent/pom.xml</relativePath>
</parent>
④删除子工程中的重复信息
groupId
artifactid
⑤在子工程中找到被父工程管理的依赖信息,删除版本号部分
⑥在父工程中统一修改已管理的依赖信息的版本号,看是否能够控制所有子工程
6.聚合
配置继承后,要先安装父工程;否则子工程就没法安装;
如果要将父工程和其所有的子工程一起安装;可以利用聚合;
聚合的作用是一起安装;
配置:在总的聚合工程中加入如下信息
例如:Hello、HelloFriend、MakeFriends都是Parent的子模块;
可在 Parent工程的pom.xml中添加聚合配置;
<modules>
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriends</module>
</modules>
输入:mvn install 安装Parent时,其子工程也会一起安装;
注意:聚合和继承没有必然的联系;
7.自动化部署(不常用)
8.网址
我们可以到http://mvnrepository.com/搜索需要的jar包的依赖信息。