Maven学习笔记

zoukankan html css js c++ java

Maven学习笔记
Maven学习笔记

1、学习目标

会使用maven构建项目的命令

会使用maven构建java项目和java web项目

依赖管理--传递依赖版本冲突处理

在web的单个工程中实现jsp+servlet整合。

分模块构建工程

会向私服上传jar包。会从私服下载jar包

2、Maven介绍

2.1 maven是什么

maven翻译为“专家”，“内行”。

Maven是Apache下的一个纯java开发的开源项目，它是一个项目管理工具，使用maven对java项目进行构建、依赖管理。当前使用Maven的项目在持续增长。

2.2 什么是项目构建

项目构建是一个项目从编写源代码到编译、测试、运行、打包、部署、运行的过程

2.3 构建过程

2.3.1 传统项目构建过程

传统的使用eclipse构建项目的过程如下：

2.3.2 maven项目构建过程

maven将项目构建的过程进行标准化，每个阶段使用一个命令完成，下图展示了构建过程的一些阶段，后面章节详细介绍每个阶段，这里先大概了解下：

清理 mvn clean

编译 mvn compile

测试 mvn test

报告 mvn site

打包 mvn package

部署 mvn deploy

2.4 jar依赖管理

2.4.1 传统项目的依赖管理

传统的项目工程要管理所依赖的jar包完全靠人工进行，程序员从网上下载jar包添加到项目工程中，如下图：程序员手工将Spring、SpringMVC、Mybatis的jar添加到工程中的WEB-INF/lib目录下。

手工拷贝jar包添加到工程中的问题是：

没有对jar包的版本统一管理，容易导致版本冲突。

从网上找jar包非常不方便，有些jar找不到。

jar包添加到工程中导致工程过大。

2.4.2 maven项目的依赖管理

maven项目管理所依赖的jar包不需要手动向工程添加jar包，只需要在pom.xml（maven工程的配置文件）添加jar

包的坐标，自动从maven仓库中下载jar包、运行，如下图：

使用maven依赖管理添加jar的好处：

通过pom.xml文件对jar包的版本进行统一管理，可避免版本冲突。

maven团队维护了一个非常全的maven仓库，里边包括了当前使用的jar包，maven工程可以自动从maven仓库

下载jar包，非常方便。

2.5 使用maven的好处

通过上边介绍传统项目和maven项目在项目构建及依赖管理方面的区域，maven有如下的好处：

一步构建

maven对项目构建的过程进行标准化，通过一个命令即可完成构建过程。

依赖管理

maven工程不用手动导jar包，通过在pom.xml中定义坐标从maven仓库自动下载，方便且不易出错。

maven的跨平台，可在window、linux上使用。

maven遵循规范开发有利于提高大型团队的开发效率，降低项目的维护成本，大公司都会考虑使用maven来构

建项目。

3 maven安装

3.1 下载安装

下载地址

解压

将maven解压到一个不含有中文和空格的目录中。

bin目录 mvn.bat （以run方式运行项目）、 mvnDebug.bat（以debug方式运行项目）

boot目录 maven运行需要类加载器

conf目录 settings.xml 整个maven工具核心配置文件

lib目录 maven运行依赖jar包

3.2 环境变量配置

maven环境配置，增加一个环境变量M2_HOME,值是maven的安装路径（C:Program Filesapache-maven-3.5.0-binapache-maven-3.5.0）

修改path则是在path最后面添加;%M2_HOME%in。

具体如下配置：

将 %M2_HOME%/bin 加入环境变量 path

通过 mvn -v命令检查 maven是否安装成功，看到maven的版本为3.3.9及java版本为1.8即为安装成功。

3.3 maven仓库

3.3.1 仓库有三种

本地仓库

本地仓库的默认路径为用户.m2 epository

我们可以在setting.xml中用<localRepository>D: epository</localRepository>字段修改本地仓库的路径

远程仓库

如果项目依赖的库在本地仓库中没有找到，maven就会去远程仓库找，maven有默认的远程仓库，就是他的中央仓库

镜像仓库

一般默认的远程仓库在国内可能连接不上，所以我们可以修改远程仓库的地址为国内的镜像仓库上

修改maven根目录下的conf文件夹中的setting.xml文件，内容如下：

<mirrors>
<mirror>
<id>aliyunmaven</id>
<mirrorOf>*</mirrorOf>
<name>阿里云公共仓库</name>
<url>https://maven.aliyun.com/repository/public</url>
</mirror>
</mirrors>

3.3.2 maven仓库的作用

maven的工作需要从仓库下载一些jar包，如下图所示，本地的项目A、项目B等都会通过maven软件从远程仓库

（可以理解为互联网上的仓库）下载jar包并存在本地仓库，本地仓库就是本地文件夹，当第二次需要此jar包时则不再从远程仓库下载，因为本地仓库已经存在了，可以将本地仓库理解为缓存，有了本地仓库就不用每次从远程仓库下载了。

下图描述了maven中仓库的类型：.

本地仓库：用来存储从远程仓库或中央仓库下载的插件和jar包，项目使用一些插件或jar包，优先从本地仓库查找。默认本地仓库位置在meven根目录下conf/settings.xml中，可看出： $， {user.dir}表示windows用户目录。$

远程仓库：如果本地需要插件或者jar包，本地仓库没有，默认去远程仓库下载。远程仓库可以在互联网内也可以在局域网内。

中央仓库：在maven软件中内置一个远程仓库地址http://repo1.maven.org/maven2，它是中央仓库，服务于整个互联网，它是由Maven团队自己维护，里面存储了非常全的jar包，它包含了世界上大部分流行的开源项目构件。

3.3.3 配置本地仓库

在D盘目录下创建repository文件夹：

在MAVE_HOME/conf/settings.xml文件中配置本地仓库位置：

3.3.4 全局setting与用户setting

maven仓库地址、私服等配置信息需要在setting.xml文件中配置，分为全局配置和用户配置。

全局配置：在maven安装目录下的有 conf/setting.xml文件，此setting.xml文件用于maven的所有project项目，它作为maven的全局配置。

用户配置：如需要个性配置则需要在用户配置中设置，用户配置的setting.xml文件默认的位置在： $目录中 {user.dir} 指windows 中的用户目录。$

maven会先找用户配置，如果找到则以用户配置文件为准，否则使用全局配置文件。

4、入门

4.1 约定目录

使用maven创建的工程我们称它为maven工程，maven工程具有一定的目录规范，如下：

src/main/java —— 存放项目的.java文件

src/main/resources —— 存放项目资源文件，如spring, hibernate配置文件

src/test/java —— 存放所有单元测试.java文件，如JUnit测试类

src/test/resources —— 测试资源文件

pom.xml——maven项目核心配置文件Project

4.2 创建项目

1.命令行创建普通java项目

mvn archetype:generate -DgroupId=net.wanho -DartifactId=javademo -DarchetypeArtifactId=maven-archetype-quickstart

2.命令行创建javaWeb项目

mvn archetype:generate -DgroupId=net.wanho -DartifactId=javawebdemo -DarchetypeArtifactId=maven-archetype-webapp

4.3 常用的maven命令

在cmd的状态下测试

mvn -v 查看 maven 版本
-compile 编译
-test 测试
-package 打包
-clean 删除 target
-install 安装 jar 包到本地仓库

4.3.1 compile

compile是maven工程的编译命令，作用是将src/main/java下的文件编译为class文件输出到target目录下。

cmd进入命令状态，执行mvn compile，如下图提示成功：

查看 target目录，class文件已生成，编译完成。

4.3.2 test

test是maven工程的测试命令，会执行src/test/java下的单元测试类。

cmd执行mvn test执行src/test/java下单元测试类，下图为测试结果，运行1个测试用例，全部成功。

4.3.3 clean

clean是maven工程的清理命令，执行 clean会删除target目录的内容。

4.3.4 package

package是maven工程的打包命令，对于java工程执行package打成jar包，对于web工程打成war包。

4.3.5 install

install是maven工程的安装命令，执行install将maven打成jar包或war包发布到本地仓库。

4.4 生命周期

4.4.1 三套生命周期

maven对项目构建过程分为三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，这三套生命周期分别是：

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

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

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

完整的项目构建过程包括：清理、编译、测试、打包、集成测试、验证、部署

4.4.2 maven三套独立的生命周期

clean 清理项目
1.pre-clean 执行清理前的工作
2.clean 清理上一次构建生成的所有文件
3.post-clean 执行清理后的文件

default 构建项目（最核心）
compile test package install

site 生成项目站点
1. pre-site 在生成项目站点前要完成的工作
2. site 生成项目的站点文档
3. post-site 在生成项目站点后要完成的工作
4. site-deploy 发布生成的站点到服务器上

4.4.3 命令与生命周期的阶段

每个maven命令对应生命周期的某个阶段，例如：mvn clean 命令对应clean生命周期的clean阶段， mvn test 命令对应default生命周期的test阶段。

执行命令会将该命令在的在生命周期当中之前的阶段自动执行，比如：执行mvn clean 命令会自动执行pre-clean 和clean两个阶段，mvn test命令会自动执行validate、compile、test等阶段。

注意：执行某个生命周期的某个阶段不会影响其它的生命周期！

如果要同时执行多个生命周期的阶段可在命令行输入多个命令，中间以空格隔开，例如：

clean package 该命令执行clean生命周期的clean阶段和default生命周期的package阶段。

4.5 maven的概念模型

Maven包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin) 目标(goal)的逻辑。

下图是maven的概念模型图：

项目对象模型 (Project Object Model)

一个maven工程都有一个pom.xml文件，通过pom.xml文件定义项目的坐标、项目依赖、项目信息、插件目标等。

依赖管理系统(Dependency Management System)

通过maven的依赖管理对项目所依赖的jar 包进行统一管理。

比如：项目依赖junit4.9，通过在pom.xml中定义junit4.9的依赖即使用junit4.9，如下所示是junit4.9的依赖定义：

<!‐‐ 依赖关系 ‐‐>
<dependencies>
<!‐‐ 此项目运行使用junit，所以此项目依赖junit ‐‐>
<dependency>
<!‐‐ junit的组织名称 ‐‐>
<groupId>junit</groupId>
<!‐‐ junit的模块名称 ‐‐>
<artifactId>junit</artifactId>
<!‐‐ junit版本 ‐‐>
<version>4.9</version>
<!‐‐ 依赖范围：单元测试时使用junit ‐‐>
<scope>test</scope>
</dependency>
</dependencies>

一个项目生命周期(Project Lifecycle)

使用maven完成项目的构建，项目构建包括：清理、编译、测试、部署等过程，maven将这些过程规范为一个生命周期，如下所示是生命周期的各个阶段：

maven通过执行一些简单命令即可实现上边生命周期的各个过程，比如执行mvn compile执行编译、执行mvn clean执行清理。

一组标准集合

maven将整个项目管理过程定义一组标准，比如：通过maven构建工程有标准的目录结构，有标准的生命周期阶段、依赖管理有标准的坐标定义等。

插件(plugin)目标(goal)

maven 管理项目生命周期过程都是基于插件完成的。

5、在Idea中Maven的配置与使用

5.1 配置

5.2 创建项目

5.2.1 新建一个java 项目

5.2.2 新建一个java_web项目名

5.2.2.1 创建web项目

你要选择maven然后按照下面图片的指示操作就可以了---》最后点击next按钮

点击Finish后项目开始创建

点击右下角查看进去

更新依赖

5.2.2.2 配置tomcat服务器

5.2.2.3 使用tomcat插件

pom.xml

<build>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<port>9090</port>
<path>/</path>
<uriEncoding>UTF-8</uriEncoding>
</configuration>
</plugin>
</plugins>
</build>

5.2.2.4 使用Idea的Smart插件

5.3 约定目录和pom解读

5.3.1 约定目录

使用maven创建的工程我们称它为maven工程，maven工程具有一定的目录规范，如下：

src

src/main/java —— 存放项目的.java文件

src/main/resources —— 存放项目资源文件，如spring, mybatis配置文件

src/test/java —— 存放所有单元测试.java文件，如JUnit测试类

src/test/resources —— 测试资源文件

项目名
-src
-main
-java
-package
-resources
-test
-java
-package
-resources
-pom.xml

目录创建方式

同样在main下新建test测试文件夹,再在此文件夹下新建Java测试源码文件夹和resource测试资源文件夹

也可以右键项目-选择Open Module Settings打开项目配置页面更改

5.3.2 pom 解读

pom.xml ——maven项目核心配置文件

<project>

<groupId>包名</groupId>
<artifactId>项目名</artifactId>
<version>版本</version>


<packaging>jar|war|pom</packaging>


<dependencies>

<dependency>
<groupId>包名</groupId>
<artifactId>项目名</artifactId>
<version>版本</version>
</dependency>
</dependencies>

<build>
<plugins>

<plugin>
</plugin>
</plugins>
</build>
</project>

配置依赖jar包

6.4 生命周期，各个阶段的构建过程

清理 mvn clean 把target目录删除

编译 mvn compile 编译项目，生成target 目录

测试 mvn test 执行单元测试

打包 mvn package 把项目打包成war或者jar

安装 mvn install 把jar安装到本地仓库

6.5 热部署

IDEA还有一个好处就是热部署，这个呢在实际开发中是很管用的web开发，你后台，改了啥他就热部署，不用你重启tomcat，前台的也是，你修改jsp,css,js什么的都可以直接进行热部署，你只要自己刷新一下你的页面就行了。

下面只要你运行了这个项目之后，就会自己帮你直接启动你开始设置的浏览器直接进行访问，

7 依赖管理、传递依赖和依赖冲突

7.1 依赖管理

7.1.1 什么是依赖

一个java项目可能要使用一些第三方的jar包才可以运行，那么我们说这个java项目依赖了这些第三方的jar包。比如项目依赖lombok、mysql

7.1.2 什么是依赖管理

就是对项目所有依赖，进行规范化管理，通过GAV坐标。全网唯一的GAV坐标，决定使用哪一个jar包。

依赖管理一般放在pom.xml文件中

7.1.3 添加依赖

在pom.xml中添加dependency标签，如下：

<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
</dependency

示例Junit4.9

<!‐‐ 添加junit4.9依赖 ‐‐>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
</dependency>

7.1.4 查找坐标

添加依赖需要指定依赖jar包的坐标，但是很多情况我们是不知道jar包的的坐标，可以通过如下方式查询：方法一：从互联网搜索

http://search.maven.org/

http://mvnrepository.com/

网站搜索示例：

7.2 传递依赖

7.2.1 什么是传递依赖

当 A 依赖 B、B 依赖 C ，在 A 中导入 B 后会自动导入 C ，C 是 A 的传递依赖。

举例 : junit->hmcrest

7.2.2 依赖范围对传递依赖的影响（了解）

依赖会有依赖范围，依赖范围对传递依赖也有影响，有A、B、C，A依赖B，B依赖C，C可能是A的传递依赖，如下图：

最左边一列为直接依赖，理解为A依赖B的范围，最顶层一行为传递依赖，理解为B依赖C的范围，行与列的交叉即为 A 传递依赖 C 的范围。

举例：

比如 A 对 B 有 compile 依赖，B 对 C 有 runtime 依赖，那么根据表格所示 A 对 C 有 runtime 依赖。测试

dao依赖junit的scope为test

service依赖dao.

查看下图红色框内所示传递依赖范围：

所以maven-ﬁrst所依赖的junit的jar没有加入到maven-web工程。

如果修改maven-ﬁrst依赖junit的scope为compile，maven-ﬁrst所依赖的junit的jar包会加入到maven-web工程中，符合上边表格所示，查看下图红色框内所示：

7.3 依赖冲突

什么是传递依赖

当 A 依赖 B、B 依赖 C（v1.0），

当 A 依赖 M、M 依赖 C (v2.0)

如下例子：

同时加入以下依赖，观察依赖：

<!‐‐ struts2‐spring‐plugin 依赖 spirng‐beans‐3.0.5 ‐‐>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2‐spring‐plugin</artifactId>
<version>2.3.24</version>
</dependency>

<!‐‐ spring‐context 依赖 spring‐beans‐4.2.4 ‐‐>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐context</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>

7.3.1 依赖调解原则

maven自动按照下边的原则调解：

7.3.1.1 第一声明者优先原则

在pom文件定义依赖，先声明的依赖为准。测试：

如果将上边struts-spring-plugins和spring-context顺序颠倒，系统将导入spring-beans-4.2.4。分析：

由于spring-context在前边以spring-context依赖的spring-beans-4.2.4为准，所以最终spring-beans-4.2.4添加到了工程中。

7.3.1.2 路径近者优先原则

例如：A依赖 spirng-beans-4.2.4，A依赖 B 依赖 spirng-beans-3.0.5，则spring-beans-4.2.4优先被依赖在 A 中，因为spring-beans-4.2.4相对spirng-beans-3.0.5被A依赖的路径最近。

测试：

在本工程中的pom中加入spirng-beans-4.2.4的依赖，根据路径近者优先原则，系统将导入spirng-beans-4.2.4：

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐beans</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>

7.3.2 排除依赖

上边的问题也可以通过排除依赖方法辅助依赖调解，如下：

比如在依赖struts2-spring-plugin的设置中添加排除依赖，排除spring-beans，

下边的配置表示：依赖struts2-spring-plugin，但排除struts2-spring-plugin所依赖的spring-beans。

<!‐‐ struts2‐spring‐plugin依赖spirng‐beans‐3.0.5 ‐‐>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2‐spring‐plugin</artifactId>
<version>2.3.24</version>
<!‐‐ 排除 spring‐beans‐‐>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring‐beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring‐context</artifactId>
</exclusion>
</exclusions>
</dependency>

7.4 锁定版本

面对众多的依赖，有一种方法不用考虑依赖路径、声明优化等因素可以采用直接锁定版本的方法确定依赖构件的版本，版本锁定后则不考虑依赖的声明顺序或依赖的路径，以锁定的版本的为准添加到工程中，此方法在企业开发中常用。

如下的配置是锁定了spring-beans和spring-context的版本：

<dependencyManagement>
<dependencies>
<!‐‐这里锁定版本为4.2.4 ‐‐>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐beans</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐context</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>

注意：在工程中锁定依赖的版本并不代表在工程中添加了依赖，如果工程需要添加锁定版本的依赖则需要单独添加

<dependencies></dependencies>标签，如下：

<dependencies>
<!‐‐这里是添加依赖 ‐‐>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring‐context</artifactId>
</dependency>
</dependencies>

上边添加的依赖并没有指定版本，原因是已在<dependencyManagement中锁定了版本，所以在<dependency> 下不需要再指定版本。

7.5 依赖范围

maven提供了6种可选依赖范围:

compile：编译范围，指A在编译时依赖B，此范围为默认依赖范围。编译范围的依赖会用在编译、测试、运行，由于运行时需要所以编译范围的依赖会被打包。

provided：provided依赖：只有在当JDK或者一个容器已提供该依赖之后才使用， provided依赖在编译和测试时需要，在运行时不需要，比如：servlet api被tomcat容器提供。

runtime：runtime依赖：在运行和测试系统的时候需要，但在编译的时候不需要。比如：jdbc的驱动包。由于运行时需要所以runtime范围的依赖会被打包。

test：test范围依赖：在编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用，比如：junit。由于运行时不需要所以test范围依赖不会被打包。

system：system范围依赖：与provided类似，但是你必须显式的提供一个对于本地系统中JAR文件的路径，需要指定systemPath磁盘路径，system依赖不推荐使用。

import: 导入范围，他只是用在 dependencyManagement 中，表示从其他的 pom 中导入dependecy的配置。（以下引用官网案例并不难理解。）

在maven-web工程中测试各个scope。

总结：

默认引入的jar包------- compile 【默认范围可以不写】（编译、测试、运行都有效）

servlet-api 、jsp-api------- provided （编译、测试有效，运行时无效防止和tomcat下jar冲突）

jdbc驱动jar包---- runtime （测试、运行有效）

junit----- test （测试有效）

依赖范围由强到弱的顺序是：compile>provided>runtime>test

7、聚合与继承

7.1 聚合

<modelVersion>4.0.0</modelVersion>

<groupId>net.wanho</groupId>
<artifactId>wanlimall_parent</artifactId>
<version>1.0</version>

<modules>
<module>wanliweb</module>
</modules>

<packaging>pom</packaging>

假设在HoictasStudio-MavenParent模块中添如以上代码，输入clean install命令后，即可同时安装多个jar到本地仓库中

[INFO] HoictasStudio-MavenDemo01 .......................... SUCCESS [ 4.618 s]
[INFO] HoictasStudio-MavenDemo02 .......................... SUCCESS [ 0.828 s]
[INFO] HoictasStudio-MavenDemo03 .......................... SUCCESS [ 0.923 s]
[INFO] HoictasStudio-MavenParent .......................... SUCCESS [ 0.021 s]

7.2 继承

子模块可以继承父模块的内容

7.2.1 语法示例

那么，我们需要my-module去继承my-app，则需要在my-module的pom文件中添加以下代码：

<parent>
<artifactId>wanlimall_parent</artifactId>
<groupId>net.wanho</groupId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>

<artifactId>wanliweb</artifactId>
<packaging>war</packaging>

8、properties介绍

可以理解成定义的版本变量


<properties>
<junit_version>4.12</junit_version>
</properties>


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

<version>${junit_version}</version>
<scope>test</scope>
<exclusions>
<exclusion>
<artifactId>hamcrest-core</artifactId>
<groupId>org.hamcrest</groupId>
</exclusion>
</exclusions>
</dependency>

9、dependencyManagement与pluginManagement

dependencyManagement一般统一在父模块中进行声明，使用：其实相当于一个对所有依赖jar包进行版本管理统一声明管理，但父模块中只是声明，并不真导入。

parent/pom.xml

<dependencyManagement>
<dependencies>

<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.9.3</version>
</dependency>

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

child/pom.xml

<parent>
<artifactId>parent</artifactId>
<groupId>net.wanhe</groupId>
<version>1.0-SNAPSHOT</version>
</parent>

<dependencies>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
</dependency>

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

pluginManagement理解同dependencyManagement

10、总结

10.1 maven仓库

maven仓库的类型有哪些？

maven工程查找仓库的流程是什么？

本地仓库如何配置？

10.2 常用的maven命令

常用的maven命令包括：

compile：编译

clean：清理

test：测试

package：打包

install：安装

10.3 坐标定义

在pom.xml中定义坐标，内容包括：groupId、artifactId、version，详细内容如下：

<!‐‐项目名称，定义为组织名+项目名，类似包名‐‐>
<groupId>net.wanho</groupId>
<!‐‐模块名称‐‐>
<artifactId>market‐parent</artifactId>
<!‐‐当前项目版本号，snapshot为快照版本即非正式版本，release为正式发布版本‐‐>
<version>0.0.1‐SNAPSHOT</version>
<!‐‐打包类型‐‐>
<packaging>pom</packaging>

11、maven私服

正式开发，不同的项目组开发不同的工程。

11.1 需求

问题：项目组编写了一个通用的工具类，其它项目组将类拷贝过去使用，当工具类修改bug后通过邮件发送给各各项目组，这种分发机制不规范可能导致工具类版本不统一。

解决方案：项目组将写的工具类通过maven构建，打成jar，将jar包发布到公司的maven仓库中，公司其它项目通过maven依赖管理从仓库自动下载jar包。

11.2 分析

公司在自己的局域网内搭建自己的远程仓库服务器，称为私服，私服服务器即是公司内部的maven远程仓库，每个员工的电脑上安装maven软件并且连接私服服务器，员工将自己开发的项目打成jar并发布到私服服务器，其它项目组从私服服务器下载所依赖的构件（jar）。

私服还充当一个代理服务器，当私服上没有jar包会从互联网中央仓库自动下载，如下图：

11.3 搭建私服环境

## 查找nexus3镜像
docker search nexus3
## 拉取nexus3镜像
docker pull docker.io/sonatype/nexus3
## 查看镜像
docker images
## 创建目录
mkdir -p /root/docker/nexus3/data
## 运行nexus容器
docker run -id --privileged=true --name=nexus3 --restart=always -p 8081:8081 -p 8082:8082 -p 8083:8083 -v /root/docker/nexus3/data:/nexus-data sonatype/nexus3
## 访问
http://192.168.100.205:8081
## 右上角登录，用户名 admin
## 密码，进入查看
docker exec -it nexus3 /bin/bash
vi /nexus-data/admin.password

11.4 将项目发布到私服

11.4.1 需求

企业中多个团队协作开发通常会将一些公用的组件、开发模块等发布到私服供其它团队或模块开发人员使用。

团队分别开发dao、service、web，某个团队开发完在dao会将dao发布到私服供service团队使用，本例子会将dao工程打成jar包发布到私服。

11.4.2 配置

第一步：需要在客户端即部署dao工程的电脑上配置 maven环境，并修改 settings.xml 文件，配置连接私服的用户和密码。

此用户名和密码用于私服校验，因为私服需要知道上传的账号和密码是否和私服中的账号和密码一致。

<server>
<id>maven-releases</id>
<username>admin</username>
<password>admin</password>
</server>
<server>
<id>maven-snapshots</id>
<username>admin</username>
<password>admin</password>
</server>

releases 连接发布版本项目仓库

snapshots 连接测试版本项目仓库

第二步：配置项目pom.xml

配置私服仓库的地址，本公司的自己的jar包会上传到私服的宿主仓库，根据工程的版本号决定上传到哪个宿主仓库，如果版本为release则上传到私服的release仓库，如果版本为snapshot则上传到私服的snapshot仓库


<distributionManagement>
<repository>
<id>maven-releases</id>
<name>Nexus Release Repository</name>
<url>http://192.168.100.205:8081/repository/maven-releases/</url>
</repository>
<snapshotRepository>
<id>maven-snapshots</id>
<name>Nexus Snapshot Repository</name>
<url>http://192.168.100.205:8081/repository/maven-snapshots/</url>
</snapshotRepository>
</distributionManagement>

注意：pom.xml这里和 settings.xml 配置对应！

11.4.3 操作命令

将项目dao工程打成jar包发布到私服：

首先启动nexus

对dao工程执行deploy命令

根据本项目pom.xml中version定义决定发布到哪个仓库，如果version定义为snapshot，执行deploy后查看nexus 的snapshot仓库，如果version定义为release则项目将发布到nexus的release仓库，本项目将发布到snapshot仓库

11.5 从私服下载jar包

11.5.1 需求

没有配置nexus之前，如果本地仓库没有，去中央仓库下载，通常在企业中会在局域网内部署一台私服服务

器，有了私服本地项目首先去本地仓库找jar，如果没有找到则连接私服从私服下载jar包，如果私服没有jar包

私服同时作为代理服务器从中央仓库下载jar包，这样做的好处是一方面由私服对公司项目的依赖jar包统一管

理，一方面提高下载速度，项目连接私服下载jar包的速度要比项目连接中央仓库的速度快的多。

11.5.2 管理仓库组

nexus中包括很多仓库，hosted中存放的是企业自己发布的jar包及第三方公司的jar包，proxy中存放的是中央仓库的jar，为了方便从私服下载jar包可以将多个仓库组成一个仓库组，每个工程需要连接私服的仓库组下载jar包。

上图中仓库组包括了本地仓库、代理仓库等。

11.5.3 两种方式

11.5.3.1 pom.xml中配置

<repositories>
<repository>
<id>nexus_public</id>
<name>Nexus_public</name>
<url>http://192.168.100.205:8081/repository/maven-public/</url>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>

11.5.3.2 在setting.xml中配置仓库（全局）

在客户端的setting.xml中配置私服的仓库，由于setting.xml中没有repositories的配置标签需要使用proﬁle定义仓库。

<profile>
<id>dev</id>
<repositories>
<repository>

<id>local-nexus</id>

<url>http://192.168.100.205:8081/repository/maven-public/</url>
<releases>

<enabled>true</enabled>
</releases>
<snapshots>

<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>

<pluginRepository>

<id>public</id>
<name>Public Repositories</name>
<url>http://192.168.100.205:8081/repository/maven-public/</url>
</pluginRepository>
</pluginRepositories>
</profile>

使用proﬁle定义仓库需要激活才可生效。

<activeProfiles>
<activeProfile>dev</activeProfile>
</activeProfiles>
出处：https://www.cnblogs.com/helloxiaojie/p/14906654.html
您的资助是我最大的动力！
金额随意,欢迎来赏！
付款后有任何问题请给我留言。

如果，您希望更容易地发现我的新博客，不妨点击一下绿色通道的【关注我】。(●'◡'●)

如果你觉得本篇文章对你有所帮助，请给予我更多的鼓励，求打 付款后有任何问题请给我留言!!!

因为，我的写作热情也离不开您的肯定支持，感谢您的阅读，我是【Jack_孟】！
查看全文

相关阅读:
小总结下iphone开发环境搭建过程！
Raspberry Pi之旅【序】
linux虚拟机中配置samba的实现文件共享的方法
 编写高质量的代码1尽量使用StringBuilder
ArcEngine开发点滴1
开源Firebird .NET Provider V0.9.0.0发布
 .NET的Ant构建系统 NAnt 0.91发布！
iis7.5 发布rest服务，put请求返回404错误解决方法
 COM学习笔记(1)
2004年南京美食地图 [转载]

原文地址：https://www.cnblogs.com/mq0036/p/14914287.html

Maven学习笔记

1、学习目标

2、Maven介绍

2.1 maven是什么

2.2 什么是项目构建

2.3 构建过程

2.3.1 传统项目构建过程

2.3.2 maven项目构建过程

2.4 jar依赖管理

2.4.1 传统项目的依赖管理

2.4.2 maven项目的依赖管理

2.5 使用maven的好处

3 maven安装

3.1 下载安装

3.2 环境变量配置

3.3 maven仓库

3.3.1 仓库有三种

3.3.2 maven仓库的作用

3.3.3 配置本地仓库

3.3.4 全局setting与用户setting

4、入门

4.1 约定目录

4.2 创建项目

4.3 常用的maven命令

4.3.1 compile

4.3.2 test

4.3.3 clean

4.3.4 package

4.3.5 install

4.4 生命周期

4.4.1 三套生命周期

4.4.2 maven三套独立的生命周期

4.4.3 命令与生命周期的阶段

4.5 maven的概念模型

5、在Idea中Maven的配置与使用

5.1 配置

5.2 创建项目

5.2.1 新建一个java 项目

5.2.2 新建一个java_web项目名

5.2.2.1 创建web项目

5.2.2.2 配置tomcat服务器

5.2.2.3 使用tomcat插件

5.2.2.4 使用Idea的Smart插件

5.3 约定目录和pom解读

5.3.1 约定目录

5.3.2 pom 解读

6.4 生命周期，各个阶段的构建过程

6.5 热部署

7 依赖管理、传递依赖和依赖冲突

7.1 依赖管理

7.1.1 什么是依赖

7.1.2 什么是依赖管理

7.1.3 添加依赖

7.1.4 查找坐标

7.2 传递依赖

7.2.1 什么是传递依赖

7.2.2 依赖范围对传递依赖的影响（了解）

7.3 依赖冲突

7.3.1 依赖调解原则

7.3.1.1 第一声明者优先原则

7.3.1.2 路径近者优先原则

7.3.2 排除依赖

7.4 锁定版本

7.5 依赖范围

7、聚合与继承

7.1 聚合

7.2 继承

7.2.1 语法示例

8、properties介绍

9、dependencyManagement与pluginManagement

10、总结

10.1 maven仓库

10.2 常用的maven命令

10.3 坐标定义

11、maven私服

11.1 需求

11.2 分析

11.3 搭建私服环境

11.4 将项目发布到私服