maven学习

Maven学习

1、maven最开始

1.自己建三个在同一路径下的项目（不需要骨架）

2.由于自己导jar包，idea会从中央仓库到外网下载，速度慢，所以配置一些东西

1. 找到apache-maven-3.5.0—conf—settings.xml

2. 55行<localRepository>指定本地仓库的路径</localRepository>（idea中可以改，配置文件里删了也可以）

3. 通过ali镜像下载，settings.xml里添加如下代码

 <mirror>
       <id>alimaven</id>
       <mirrorOf>central</mirrorOf>
       <name>aliyun maven</name>
       <url>http://maven.aliyun.com/nexus/content/groups/public</url>
     </mirror>
 ​
     <mirror>
       <id>repo2</id>
       <mirrorOf>central</mirrorOf>
       <name>repo2 maven</name>
       <url>http://repo2.maven.org/maven2</url>
     </mirror>
 ​
 ​
     <mirror>
       <id>uk</id>
       <mirrorOf>central</mirrorOf>
       <name>Human Readable Name for this Mirror.</name>
       <url>http://uk.maven.org/maven2</url>
     </mirror>
 ​
 ​
     <mirror>
       <id>nexus</id>
       <mirrorOf>central</mirrorOf>
       <name>internal nexus repository</name>
       <url>http://repo.maven.apache.org/maven2</url>
     </mirror>
   </mirrors>

1.修改setting

2.以后仓库默认路径

3.开始下载 显示之间的依赖关系（HelloFriend依赖Hello，MakeFriend依赖HelloFriend）

4.给依赖

注：我们可以到maven酷站上搜索需要的jar包的依赖信息。

5.Hello中jar给17，HelloFriend中jar给14，MakeFriend依赖结果是14

提问，为什么用1.2.14不用17呢？

自动剔除有两种思想：

1. 最短路径优先（HelloFriend依赖Hello，MakeFriend依赖HelloFriend）

2. 路径相同时先声明者优先（HelloFriend依赖Hello，MakeFriend依赖Hello，dependency先声明谁就依赖谁）

针对上图，maven自动处理用的是最短路径优先，后边的自动剔除了实例

maven找依赖的顺序：

1. 根据gav(坐标)在本地仓库中查找

2. 根据gav在远程服务器中下载，下载在本地仓库

3. 如果都没有就是你乱输的

 

现在以crm为例 用maven构造 模块之间相分离：

 

依赖关系：

controller 依赖 service

service 依赖 mapper

mapper 依赖 bean

以上都可能依赖 utils，所以

bean 依赖 utils 所以（每个模块能分开开发! 因为高内聚低耦合）

 

2、构建环节

①清理：删除以前的编译结果，为重新编译做好准备。

②编译：将Java源程序编译为字节码文件。

③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。

④报告：在每一次测试后以标准的格式记录和展示测试结果。

⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。

⑥安装：在Maven环境下特指将打包的结果——jar包或war包安装到本地仓库中。

⑦部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。

 

3、Maven核心概念

Maven之所以能够实现自动化的构建，和它的设计是紧密相关的。我们对Maven的学习就围绕它的九个核心概念展开：

①POM

②约定的目录结构

③坐标

④依赖管理

⑤仓库管理

⑥生命周期

⑦插件和目标

⑧继承 父工程(又可以作为聚合工程) 1.统一管理子工程jar的版本2.可以一键安装所有子工程

⑨聚合

 

4、POM

Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。

5、 约定的目录结构

现在JavaEE开发领域普遍认同一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。而Maven正是因为指定了特定文件保存的目录才能够对我们的Java工程进行自动化构建。

目录结构含义参见前面的描述。

6、 坐标

[1]在一个平面中使用x、y两个向量可以唯一的确定平面中的一个点。

[2]在空间中使用x、y、z三个向量可以唯一的确定空间中的一个点。

6.1、Maven的坐标

使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程。

[1]groupId：公司或组织的域名倒序+当前项目名称

[2]artifactId：当前项目的模块名称

[3]version：当前模块的版本

     <groupId>com.galaxy.maven</groupId>
     <artifactId>Hello</artifactId>
     <version>0.0.1-SNAPSHOT</version>

6.2、如何通过坐标到仓库中查找jar包

[1]将gav三个向量连起来

 com.galaxy.maven+Hello+0.0.1-SNAPSHOT

[2]以连起来的字符串作为目录结构到仓库中查找

 com/galaxy/maven/Hello/0.0.1-SNAPSHOT/Hello**-**0.0.1-SNAPSHOT.jar

※注意：我们自己的Maven工程必须执行安装操作才会进入仓库。安装的命令是：mvn install

7、关键：对Hello的依赖

这里Hello就是我们的第一个Maven工程，现在HelloFriend对它有依赖。那么这个依赖能否成功呢？更进一步的问题是：HelloFriend工程会到哪里去找Hello呢？

答案是：本地仓库。任何一个Maven工程会根据坐标到本地仓库中去查找它所依赖的jar包。如果能够找到则可以正常工作，否则就不行。

 

依赖管理

1.基本概念

当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。例如：commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar。

通过第二个Maven工程我们已经看到，当前工程会到本地仓库中根据坐标查找它所依赖的jar包。

配置的基本形式是使用dependency标签指定目标jar包的坐标。

例：commons-fileupload-1.3.jar导入到本地仓库，commons-io-2.0.1.jar会自动导入

2.直接依赖和间接依赖

如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。

3.依赖的范围

当一个Maven工程添加了对某个jar包的依赖后，这个被依赖的jar包可以对应下面几个可选的范围：

①compile默认的

[1]main目录下的Java代码可以访问这个范围的依赖

[2]test目录下的Java代码可以访问这个范围的依赖，在其他地方不能用 如：点进去看

[3]部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下

例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。

②test

[1]main目录下的Java代码不能访问这个范围的依赖

[2]test目录下的Java代码可以访问这个范围的依赖

[3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

例如：对junit的依赖。仅仅是测试程序部分需要。

③provided

[1]main目录下的Java代码可以访问这个范围的依赖

[2]test目录下的Java代码可以访问这个范围的依赖

[3]部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。

④runtime[了解]

[1]main目录下的Java代码不能访问这个范围的依赖

[2]test目录下的Java代码可以访问这个范围的依赖

[3]部署到Tomcat服务器上运行时会放在WEB-INF的lib目录下

例如：JDBC驱动。只有在测试运行和在服务器运行的时候才决定使用什么样的数据库连接。

⑤其他：import、system等。

使用场景：点击查看

依赖的传递性

当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。例如：

Maven工程	依赖范围	对A的可见性
A B C	compile	√
D	test	×
E	provided	×

依赖的排除

maven点击Show Dependencies...，选择需要排除的依赖右击Exclude刷新即可

统一管理目标jar包的版本

以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-core、spring-context等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-core的同时使用4.1.1的spring-context。

 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-core</artifactId>
     <version>4.0.0.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-context</artifactId>
     <version>4.0.0.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-jdbc</artifactId>
     <version>4.0.0.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-orm</artifactId>
     <version>4.0.0.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-web</artifactId>
     <version>4.0.0.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-webmvc</artifactId>
     <version>4.0.0.RELEASE</version>
 </dependency>

问题是如果我们想要将这些jar包的版本统一升级为4.1.1，是不是要手动一个个修改呢？显然，我们有统一配置的方式：

 <properties>
     <spring.version>4.1.1.RELEASE</spring.version>
 </properties>
 ……
         <dependency>
             <groupId>org.springframework</groupId>
             <artifactId>spring-core</artifactId>
             <version>${spring.version}</version>
         </dependency>
         <dependency>
             <groupId>org.springframework</groupId>
             <artifactId>spring-context</artifactId>
             <version>${spring.version}</version>
         </dependency>
         <dependency>
             <groupId>org.springframework</groupId>
             <artifactId>spring-jdbc</artifactId>
             <version>${spring.version}</version>
         </dependency>
         <dependency>
             <groupId>org.springframework</groupId>
             <artifactId>spring-orm</artifactId>
             <version>${spring.version}</version>
         </dependency>
         <dependency>
             <groupId>org.springframework</groupId>
             <artifactId>spring-web</artifactId>
             <version>${spring.version}</version>
         </dependency>
         <dependency>
             <groupId>org.springframework</groupId>
             <artifactId>spring-webmvc</artifactId>
             <version>${spring.version}</version>
         </dependency>

这样一来，进行版本调整的时候只改一改地方就行了。

8、仓库

8.1、仓库分类

[1]本地仓库：为当前本机电脑上的所有Maven工程服务。

[2]远程仓库

(1)私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。图

(2)中央仓库：架设在Internet上，为全世界所有Maven工程服务。

(3)中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。

8.2、仓库中的文件

[1]Maven的插件

[2]我们自己开发的项目的模块

[3]第三方框架或工具的jar包

※不管是什么样的jar包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖。

9、生命周期

1.什么是Maven的生命周期

●Maven生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven就可以自动化的执行构建命令了。

●Maven有三套相互独立的生命周期，分别是：

①Clean Lifecycle在进行真正的构建之前进行一些清理工作。

②Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。

③Site Lifecycle生成项目报告，站点，发布站点。

再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean，这个clean是Clean生命周期的一个阶段。有Clean生命周期，也有clean阶段。

具体的看自己的文档（小王）

**10、继承

10.1、为什么需要继承机制

由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。例如：

 Hello   <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.9</version>
     <scope>test</scope>
 </dependency>
 HelloFriend <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.9</version>
     <scope>test</scope>
 </dependency>
 MakeFriend  <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.9</version>
     <scope>test</scope>
 </dependency>

此时如果项目需要将各个模块的junit版本统一为4.9，那么到各个工程中手动修改无疑是非常不可取的。使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。

10.2、创建父工程

创建父工程和创建一般的Java工程操作一致，唯一需要注意的是：打包方式处要设置为pom。

10.3、在子工程中引用父工程

 <parent>
     <!-- 父工程坐标 -->
     <groupId>...</groupId>
     <artifactId>...</artifactId>
     <version>...</version>
     <relativePath>从当前目录到父项目的pom.xml文件的相对路径</relativePath>
 </parent>

 <parent>
     <groupId>com.galaxy.maven</groupId>
     <artifactId>Parent</artifactId>
     <version>0.0.1-SNAPSHOT</version>
     
     <!-- 指定从当前子工程的pom.xml文件出发，查找父工程的pom.xml的路径 -->
     <relativePath>../Parent/pom.xml</relativePath>
 </parent>

此时如果子工程的groupId和version如果和父工程重复则可以删除。

10.4、在父工程中管理依赖

将Parent项目中的dependencies标签，用dependencyManagement标签括起来

 <dependencyManagement>
     <dependencies>
         <dependency>
             <groupId>junit</groupId>
             <artifactId>junit</artifactId>
             <version>4.9</version>
             <scope>test</scope>
         </dependency>
     </dependencies>
 </dependencyManagement>

在子项目中重新指定需要的依赖，删除范围和版本号

 <dependencies>
     <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
     </dependency>
 </dependencies>

 

11、聚合

11.1、为什么要使用聚合

图片将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean操作。而使用了聚合之后就可以批量进行Maven工程的安装、清理工作。

父工程默认就是一个聚合工程

11.2、如何配置聚合

在总的聚合工程中使用modules/module标签组合，指定模块工程的相对路径即可

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

 复习看不懂就看自己写的crm小写