maven学习笔记

现在项目中存在一个问题

1.以前划分模块：以package来划分，最好每一个模块对应一个工程，借助于maven可以将项目拆分成多个工程。

2.项目中需要的jar包必须手动“复制”、粘贴到WEB-INF/lib目录下，不同项目中的jar包会重复出现，maven可以放放仓库中，需要使用时，引用即可（可联想到运行时环境。。。。运行时环境也是引用了jar包）

3.jar包需要到官网下，使用maven可以以一种规范的方式下载jar包。所有知名框架或者第三方工具的jar包都已经按照统一规范?maven的中央仓库中。

tips:“统一的规范”非常重要

4.一个jar包依赖其他jar需要手动加入到项目中，依赖易冲突

 

maven 是什么 what

　　maven是一款服务于Java平台的自动化构建平台

　　构建工具发展过程：Mark--》Ant-->maven-->gradle

　　构建：

　　　　[1].以“Java源文件”，“框架配置文件”，“jsp”,“图片”等资源为原材料，去生产一个可以运行的项目的过程

　　　　编译

　　　　部署

　　　　搭建

　　　　[2].编译：Java源文件--》编译--》class字节码文件--》交给maven执行

　　　　[3].部署：一个BS项目最终运行的动态WEB工程本身，而是运行编译的结果。简言之，就是把编译的结果拿到服务器上。

　　构建过程中的各个环节：

　　　　清理：删除旧的class文件

　　　　编译：把Java源程序编译成class字节码

　　　　测试：自动测试，自动调用Junit

　　　　报告：测试程序执行结果

　　　　打包：动态web工程打的是war，Java工程打jar包

　　　　安装：将打包得到的文件复制到仓库中的指定位置；

　　　　部署：将war包复制到servlet容器的指定目录下。

　　maven 安装程序，自行百度

　　　　1.配置java_home

　　　　2.解压maven压缩包,非中文无空格的目录下

　　　　3.配置maven的环境

　　　　4.运行mvn -v：出现版本号表明安装成功

 

　　maven核心概念：

　　　　1.约定的目录结构

　　　　2.pom

　　　　3.坐标

　　　　4.依赖

　　　　5.仓库

　　　　6.生命周期/插件/目标

　　　　7.继承

　　　　8.聚合

　　创建一个目录结构：

　　　　根目录,就是工程名字

　　　　src:源码

　　　　pom.xml

　　　　main：存放主程序

　　　　test：测试程序

　　　　Java：Java源文件

　　　　resources：配置文件/其他工具的配置文件。。。。。

　　　　为什么要遵循约定的目录结构：

　　　　　　maven负责项目的自动化构建，以编译为例，maven必须知道Java源文件保存在哪里。

　　　　　　如果自定义东西想要框架知道，有两种方式：1.配置方式，2.内部存在的约定

　　常用命令：

　　　　执行与构建过程相关的命令：必须进入pom.xml目录

　　　　mvn clean：清楚

　　　　mvn compile：编译，还可能会自动下载东西

　　　　mvn test-compile：测试编译

　　　　mvn test：测试

　　　　mvn package:打包

　　关于联网的问题：

　　　　maven 核心程序仅定义了生命周期，具体的工作还是需要特定的插件来完成，而插件本身并不包含在maven的核心程序中1

　　　　当执行的maven的命令，需要用到的插件时，先到本地仓库查看，默认本地仓库为当前家目录；

　　　　当maven核心程序如果在本地仓库中找不到需要的插件，那么他自动连接到外网，到中央仓库下载

　　　　如果此时无法连接到外网，则构建失败；

　　　　修改默认本地仓库位置可以让maven核心程序到我们事先准备好的目录下查找插件

　　　　　　找到maven解压目录

　　　　　　在setting.xml文件中找到localrepository标签

　　　　　　<localRepository>/Users/lixiuming/Documents/repository</localRepository>从注释中取出，更改maven仓库

　　pom

　　　　1.含义：project object model 项目对象模型

　　　　　　dom document object model 文档对象模型

　　　　2.pom.xml是maven工程的核心配置文件，与构建过程相关的一起设置都在这个文件中配置

　　　　　　重要程度相对于web.xml

　　坐标：

　　　　数学中的坐标：~

　　　　maven中的坐标，使用三个向量在仓库中唯一定位一个maven 工程

　　　　　　1.groupID:公司或组织域名倒叙+项目名  <groupid>com.atguigu.maven </groupid>

　　　　　　2.artifactid:模块的名称 <artifactid>hello</artifactid>

　　　　　　3.version:版本 <version>1.0.0</version>

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

　　　　　　<groupid>com.atguigu.maven </groupid>

　　　　　　<artifactid>hello</artifactid>

　　　　　　<version>1.0.0</version>

　　　　仓库位置：com/atguigu/maven/hello/1.0.0/hello-1.0.0.jar

　　仓库：

　　　　仓库的分类：本地仓库（当前电脑的仓库），远程仓库（局域网[私服]、中央仓库、中央仓库的镜像）

　　　　仓库中保存的内容：maven工程

　　　　maven自身所需要的插件

　　　　第三方框架活工具的jar包。第一方：jdk，第二方：自己，第三方：工具

　　　　自己开发的maven工程

　　依赖

　　　　maven解析依赖信息时，会到本地仓库中查找被依赖的jar包

　　　　对自己开发的maven工程，使用install命令会进入仓库 hello install

　　　　依赖的范围scope(默认是compile)：

　　　　　　1.compile

　　　　　　　　对主程序是否有效

　　　　　　　　对测试程序是否有效

　　　　　　　　参与打包

　　　　　　2.test

　　　　　　　　对测试程序是否有效

　　　　　　3.provided（面向开发过程）

　　　　　　　　　　对主程序是否有效

 

　　　　　　　　　　对测试程序是否有效（只在开发过程中被依赖，有服务器提供）

 

　　　　传递性：

　　　　　　好处：可以传递的依赖不必在每个模块工程中都重复声明，在“最下面的工程”依赖一次即可

　　　　　　注意：非compile范围的不能传递,在各个工程模块中，如果有需要就得重复声明依赖。

　　　　依赖的排除：

　　　　　　当遇到不稳定的jar包时，不希望加入当前工程则需要排除

　　　　依赖排除的设置：

　　　　　　<exclusion>

　　　　　　　　<groupId>XXX</groupId>

　　　　　　　　<artifactId>XXXX</artifactId>

　　　　　　</exclusion>

　　　　依赖的原则：

　　　　　　1.作用：解决模块工程之间jar包冲突

　　　　　　2.情景设定1：验证路径最短者优先原则

　　　　　　3.情景设定2：路径相同时，先声明者优先。这里先声明式指dependency标签的声明顺序

　　　　统一管理依赖的版本：

　　　　　　1.情景设定：spring版本为4.0，若想升级为4.3

　　　　　　　　使用properties标签内使$(自定义标签名)引用声明的版本号

  　　　　　　　　<properties>

　　　　　　　　　　  <atguigu.spring.version>4.0.0.RELEASE</atguigu.spring.version>

  　　　　　　　　</properties>

 

  　　　　　　　　<dependencies>

　　　　　　　　　　  <dependency>

 　　　　　　　　　　　　 <groupId>org.springframework</groupId>

  　　　　　　　　　　　　 <artifactId>spring-core</artifactId>

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

　　　　　　　　  </dependency>

　　　　　　2.其实properties标签配合自定义标签声明数据的配置并不是只能用于版本号。凡是需要统一声明再应用的场合都可以使用

　　　继承：

　　　　　　现在：hello 依赖Junit：4.0

　　　　　　　　　hellofriend依赖Junit：4.0

　　　　　　　　　makefriend依赖的Junit：4.9

　　　　　　需求：统一管理各个模块工程中对Junit依赖的版本

　　　　　　　　test范围的依赖，因为不能传递，所以会分散。

　　　　　　解决思路：将Junit依赖版本统一提取到父工程中，在子工程中声明依赖时不指定版本，以父工程中设定为准，便于修改，

　　　　　　　　1.创建一个maven工程作为父工程，注意，打包方式为pom

　　　　　　　　2.子工程中声明对父工程的引用,在子工程中声明父工程

　　　　　　　　　　<parent>

　　　　　　　　　　　　<groupId>com.atguigu.maven</groupId>

　　　　　　　　　　　　<artifactId>Parent</artifactId>

　　　　　　　　　　　　<version>0.0.1-SNAPSHOT</version>

　　　　　　　　　　　　<!-- 以当前工程的pom.xml文件为基准的父工程POM.XML文件的相对路径 -->

　　　　　　　　　　　　<relativePath>../Panrent/pom.xml</relativePath>

　　　　　　　　　　　</parent>

　　　　　　3.将子工程的坐标与父工程坐标中重复的内容删除,会有提示，不删也可以

　　　　　　4.在父工程中统一声明Junit依赖

　　　　　　　　<!-- 配置依赖的管理 -->

　　　　　　　　 <dependencyManagement>

  　　　　　　　　　 <dependencies>

 　　　　　　　　　　 <dependency>

  　　　　　　 　　　　　　<groupId>junit</groupId>

　　　　　　  　　　　 　　<artifactId>junit</artifactId>

　　　　　　  　　　　　　 <version>4.9</version>

　　　　  　　　　　　 </dependency>

  　　　　　　　　 </dependencies>

  　　　　　　　</dependencyManagement>

　　　　　5.在子工程中，删除Junit的依赖的版本号,若不删除，则以子类的Junit版本号为准

　　　　　　注意：配置继承后，若要安装，则要先安装父工程，否则会报错：找不到父工程

 

　　　聚合：

　　　　　　1.作用：一键安装各个模块工程

 

　　　　　　2.配置方式：在一个“总的聚合工程”

　　　　　　　　<!-- 配置聚合 -->

　　　　　　　　<modules>

　　　　　　　　　　<!-- 指定子工程的相对路径 -->

　　　　　　　　　　<module>../Hello</module>

　　　　　　　　</modules>

　　　　　　3.使用方式：在父工程的pom.xml--》右键run as--》maven install

 

　　在eclipse中使用maven

　　　　1.maven插件：eclipse内置

　　　　2.maven插件设置

　　　　　　installation：指定到maven核心程序位置，/Users/lixiuming/Documents/apache-maven-3.5.0

　　　　　　user settings:/Users/lixiuming/Documents/apache-maven-3.5.0/conf/settings.xml

　　基本操作：

　　　　创建maven版的Java工程：

　　　　　　　　

　　　　　　　　

　　　　　　　　

　　　　　　　　

　　　　　　　　

　　　　　　

　　　　创建maven版的web工程

　　　　　　区别是创建的时候选择war包。创建出来和Java项目的区别则是有webapp

　　　　　　　　

　　　　　　

　　　　　 　　　　　　　

　　　　还有一步容易忽略： Windows->Preferences-->java->Compiler-->compiler compliance level 修改版本，我这里改了1.8，若果不改，则默认是1.5

　　　　指向maven命令

　　生命周期：

　　　　各个构建环境执行的顺序：不能打乱顺序，必须按照既定的正确的顺序来执行

　　　　maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的

　　　　maven核心程序为了更好实现自动化构建，按照这一个特点执行生命周期中的各个阶段，不论现在要执行生命周期中的哪个阶段，都是从生命周期最开始的阶段执行的

　　　　插件和目标（目标：调用插件的命令）：

　　　　　　生命周期的各个阶段定义了要执行的任务是什么

　　　　　　各个阶段和插件的目标都是对应的

　　　　　　相似的目标由特定的插件来完成

转载于:https://www.cnblogs.com/lixiuming521125/p/8204131.html