学习maven的总结

学习maven的总结

目前技术中存在的问题

一个项目就是一个工程
一个项目可以借助maven就可以将项目拆分成多个工程
项目中需要的jar包必须手动复制，粘贴到WEB-INF/lib目录下
同样的jar包可以重复出现在不同的项目中，浪费存储空间，另外也让工程比较臃肿
借助maven，可以将jar包仅仅保存在仓库中，有需要使用的工程“引用”这个文件接口，并不需要真的吧jar包复制过来
Jar需要去官网下载
Tips:“统一的规范”，对整个人类社会都是非常重要

一个jar包依赖的其他的jar包必须手动加入到项目中
FIleUpload组件，commons-fileupload-1.3依赖于commons-io-2.0.1.jar

maven具体内容

maven介绍

Maven是一种服务于java平台的自动化构建工具，其他的自动化构建工具还有Make>Ant>Maven>Gradle
构建：他是一个以Java源码，jsp，html作为原材料生产出一个可以运行的项目的过程
编译：
部署
开发过程中都是，所有的路径或配置文件中的配置的类路径等都是以编译结果的目录结构为标准的。
QA小组：测试小组
构建环节
清理：将以前编译得到的旧的class字节码文件删除，为下一次的编译做准备
编译：将java源文件编译成class字节码文件
测试：自动测试，自动调用junit程序
报告：测试程序执行的结果
打包：动态Web工程打war包，java工程打jar包
安装：Maven特定的概念–将打包得到的文件复制到仓库中的指定位置
部署：将动态Web工程生成的war包复制到Servlet容器的指定，目录下，使其运行

配置maven环境

先检查java环境的变量
配置maven环境变量
MAVEN_HOME或者M2_HOME:向下兼容的意思

maven的核心概念

约定的目录结构

根目录：工程名
src目录：源码
pom.xml:maven配置的核心文件
main目录：存放主程序
Java:存放java源文件
resources目录：存放矿建或其他资源配置的文件
test:存放测试程序
为什么要遵守约定的目录结构
Maven要负责我们这个项目的自动化构建，以编译为例，maven要想自动进行编译，那么他必须知道java源文件放在那里
如果我们自定义的东西想要让框架或工具知道有两种办法：
以配置的方式明确告知框架
classpath:spring-context.xml
遵守框架内部已经存在的约定
注意，执行maven命令，必须进入pom.xml所在的目录，与构建过程相关，编译，测试，打包
Mvn clean 清理
Mvn compile执行主程序编译
Mvn test-compile执行测试编译
mvn test 执行测试
Mvn package:打包
Mvn install下载到本地仓库
Mvn site生成站点

连接外网的问题

1.maven只定义了抽象的生命周期，而其中用到的插件并不包含在maven的核心程序中
2.当我们需要用到某些插件时，maven首先会到本地仓库中查找，
3.本地仓库的位置：系统当前的用户的家目录.m2\respository
4.maven如果在本地核心程序中找不到需要的插件，那么他就会自动连接外网到中央仓库中下载
5.如果连接不上外网则构建失败

修改默认本地仓库的位置可以到我们事先准备好的目录中寻找插件

找到maven减压的目录**\conf\settings.xml**
在setting.xml文件咋中找到***localRespository***标签
将这个标签从注释中取出来，修改已经准备好的maven目录

POM

Project Object Model 项目对象模型
Pom.xml对于Maven是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置
坐标
使用三个向量唯一定位一个Maven工程
Groupid: 公司或组织域名倒序+项目
com.atguigu.maven
Artifactid:模块名
Hello
Version:版本
1.0.0

#####Maven工程的坐标与仓库中路径对应的关系

Org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar

依赖

Maven解析依赖信息时会到本地仓库中查找被依赖的jar包
对于我们自己开发的Maven工程，我们需要执行mvn install,安装后就可以进入仓库

依赖的传递

可以传递的依赖不必再每个模块中都重复声明，在最下面中依赖一次即可
非compile范围的依赖不能传递，所以在各个工程模块中，如果有需要就得重复声明依赖

依赖的排除

// An highlighted block
<exclusions>
<exclusion>
<groupId>commons-log</groupId>
<artifactId>commons-log</artfactId>
</exclusion>
</exclusions>

依赖的原则

作用：解决模块中的jar冲突问题
验证路径最短者优先

验证路径相同时先声明者优先

先声明指的是dependency标签的声明顺序

同一管理版本依赖的问题

这里对spring版本的都是4.0.0，统一修改4.1.1，手动修改不可靠
建议配置方式
使用properties标签内自定义版本号

// 
<properties>
<atguigu.spring.version>4.0.0.RESEASE</atguigu.spring.version>
</properties>

在需要统一版本的位置，使用${自定义标签名}引用声明的版本号

// 
<version>${atguigu.spring.version}</version>

凡是需要统一场合使用的度可以使用properties

依赖范围

（1）compile范围依赖
对主程序是否有效 有
对测试程序是否有效 有
是否参与打包 参与
（2）test范围依赖
对主程序是否有效 无
对测试程序是否有效 有
是否参与打包 不参与
（3）provided范围依赖
对主程序是否有效 有
对测试程序是否有效 有
是否参与打包 不参与
是否参与部署 不参与

仓库

仓库的分类：

本地仓库：当前电脑上部署的仓库目录
远程仓库：
私服：搭建在局域网上的仓库，为局域网中的maven服务

中央仓库：架设在Internet上，为全世界所有Maven工程服务
中央仓库镜像：为了分担中央仓库的流量，提升用户的访问速度，分担中央仓库的压力
仓库保存的内容：Maven工程
（1）Maven自身所需要的插件
（2）第三方框架或者工具jar包，第一方是jdk,第二方是我们自己
（3）我们自己开发的Maven工程

生命周期/插件/目标

各个环节执行的顺序，不能打乱顺序
Maven的核心程序中定义了抽象的生命周期，生命中的各个阶段都是由插件来构成的
Maven核心程序为了很好的实现自动化构建，按照这一的特点执行生命周期的各个阶段：指定生命周期的哪一阶段，都是从这个生命周期的最初位置开始执行的
插件和目标
各个阶段和插件的目标是对应的
相似的目标有特定的插件来完成
可以将目标看做调用插件功能的命令

继承

Hello依赖的junit:4.0
HelloFriend依赖的junit:4.0
MakeFriends 依赖的junit:4.9
由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致
统一管理各个模块工程中对Junit依赖的版本
解决思路：将Junit依赖统一管理到父工程中，在子工程中声明junit依赖不指定版本，以父工程中统一设定为准，同时便于修改
（1）创建一个Maven工程作为父工程，打包方式为pom

（2）在子工程中声明对父工程的引用

（3）将子工程的坐标中与父工程坐标中重复的删除

（4）在父工程中统一junit的依赖

（5）在子工程中删除junit依赖的版本号部分

聚合

作用：一键安装各个模块
配置方式：在一个总的聚合工程中配置各个参与聚合的模块

// 
<modules>
   <module>../Hello</module>
   <module>../HelloFriend</module>
   <module>../MakeFriend</module>
</modules>

使用方式“在聚合工程的pom.xml上右键>run as >maven install”

在eclipse中使用Maven

Maven插件的设置

Installations:指定Maven核心程序的位置，不介意使用Maven自带的
User settings:指定conf/settings.xml的位置，进而获取本地仓库的位置

基本操作
创建maven版的
先创建基本的maven
区分web工程和java工程的方式

想要加快maven的下载速度需要加阿里镜像

在maven的配置文件中conf/settings.xml中找到标签

nexus-aliyun
*
Nexus aliyun
http://maven.aliyun.com/nexus/content/groups/public

Maven酷站

我们可以到链接: http://mvnrepository.com/搜索