Maven
一. Maven概述
1. 实质：
-
是跨平台的项目管理工具：主要服务于基于Java平台的项目构建，依赖管理和项目信息管理
-
是Java项目快速构建工具：Maven基于约定优于配置的原则，即使用最佳实践，减少配置
Java开发领域普遍认同的一个观点：约定>配置>编码（能用配置解决的问题就不编码，能基于约定的就不配置）
2. Maven的两大核心
4.1. 依赖管理：依赖管理指的是使用Maven来管理项目中使用到的jar包
通过
pom.xml配置文件的dependencies标签，自动下载项目所需要的jar包，统一管理jar包之间的依赖关系
4.2. 项目构建：使用Maven就可以完成下图的项目构建过程
清理
编译
测试
报告
打包
部署
理想的项目构建是高度自动化，跨平台，可重用的组件，标准化的
3. Maven的生命周期
3.1. 定义
Maven的生命周期（lifecycle）是对构建过程进行的抽象。
Maven 的核心程序中仅仅定义了抽象的生命周期，而具体的操作则是由 Maven 的插件（
plugin）来完成的。
-
Maven 生命周期定义了各个构建环节的执行顺序，它将项目整体划分为一个个阶段，按顺序依次执行，也可以指定执行到某个阶段，然后结束
-
它包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有的构建步骤。
-
Maven 有三套相互独立的生命周期，分别是：
-
Clean Lifecycle 在进行真正的构建之前进行一些清理工作
-
Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等
-
Site Lifecycle 生成项目报告，站点，发布站点
-
它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期
每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比 如，运行 mvn clean，这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有 clean 阶段。
3.2. 生命周期与阶段
Maven将生命周期(lifecycle) 划分为一个个的阶段 (phase)
一系列顺序执行的阶段 (phase)，构成一个完整的生命周期(lifecycle)。
Maven 的内部有三个标准生命周期，分别是 : clean, default, site
| 标准生命周期 | 作用 |
|---|---|
clean | 项目清理 |
default(build) | 项目部署 |
site | 项目站点文档创建 |
3.3. Clean 生命周期
Clean 生命周期一共包含了三个阶段：这三个阶段按顺序全部执行完成后，才算完成了clean生命周期
clean生命周期通过clean插件(自带)完成，功能是删除由项目编译创建的target目录
-
pre-clean 执行一些需要在 clean 之前完成的工作
-
clean 移除所有上一次构建生成的文件
-
post-clean 执行一些需要在 clean 之后立刻完成的工作
3.4. Site 生命周期
site生命周期可以使用 Maven 提供的 maven-site-plugin 插件（该插件不是默认插件，需要引用）让 Maven 生成一个 Web 站点， 以站点的形式发布信息
-
pom.xml中添加以下内容：
<build> <plugins> <!--添加 maven-site-plugin 插件--> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-site-plugin</artifactId> <version>3.7.1</version> </plugin> </plugins> </build>
-
pre-site 执行一些需要在生成站点文档之前完成的工作
-
site 生成项目的站点文档
-
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
-
site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是 site 阶段和 site-deploy 阶段，用以生成和发布 Maven 站点，这可是 Maven 相当强大 的功能，Manager文档及统计数据自动生成
3.5. Default 生命周期
Default 生命周期是 Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中（列出一些重要阶段）
clean生命周期，只有一个阶段，点击clean插件即可完成。site生命周期，和程序开发的关系不大
三大生命周期中，和程序员关系最密切的 是
default(build)生命周期Maven 的插件机制是完全依赖 Maven 的生命周期的，因此理解生命周期至关重要
default lifecycle
开始
deploy
install
verify
package
test
compile
vadidate
不同于 clean生命周期和site生命周期都是单独的一个阶段，default(build)生命周期里面分为七个大阶段
integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境
跳过test单元测试：之前是在本地数据库进行单元测试，现在数据库迁移到了阿里云服务器上，所以数据库中的一些数据并没有，这样单元测试就会出错，但是能够保证项目的正确性，就可以跳过
| 核心阶段 | 注释 |
|---|---|
| validate | 验证项目是否正确，所有需要的必要资源是否可用（很少单独使用） |
| compile | 编译项目的源代码（将src/main中的java代码编译成class文件，输出到target目录下） |
| test | 使用合适的单元测试框架来测试已编译的源代码。（打包部署跳过该阶段） 将单元测试的资源文件和代码进行编译，生成的文件位于target/test-classes |
| package | 把已编译的代码（class文件，resources文件）打包成jar包、war 包等，生成的包位于target目录下 |
| verify | 集成测试：运行所有检查，验证包是否有效且达到质量标准 （很少单独使用） |
| install | 安装项目到本地仓库——将jar安装到maven本地仓库，本地的其他模块依赖该jar包时，可以直接从本地仓库去获取 |
| deploy | 发布项目到远程仓库——在集成或者发布环境下执行，将最终版本jar包部署到远端仓库，需要在maven的setting.xml中配置私服的用户名和密码，以及在pom.xml配置，使得其他的开发者或者工程可以共享 |
生命周期与自动化构建：
这七个大阶段是 顺序执行，运行任何一个阶段的时候，它前面的所有阶段都会被运行。例如运行 mvn install 的时候，代码会被编译，测试，打包——这就是 Maven 为什么能够自动执行构建过程的各个环节的原因。
指定某个生命周期的阶段
比如执行
mvn install，会依次执行validate, compile, test, package, verify，最后执行 install 阶段，将jar包发布到本地仓库。
指定多个不同生命周期的阶段
执行
mvn clean deploy命令，首先完成的 clean 生命周期，将以前构建的文件清理。然后再执行 default lifecycle 的 validate, compile, test, package, verify, insstall, deploy 阶段，将 package 阶段创建的jar包发布到远程仓库中。
4. Maven的插件
-
Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的
-
每个插件都能实现多个功能，每个功能就是一个插件目标
-
Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务
例如：compile 就是插件 maven-compiler-plugin 的一个目标；pre-clean 是插件 maven-clean-plugin 的一个目标
二. Maven核心知识
1. Maven仓库
Maven项目管理的全部jar包存储在Maven远程仓库中
-
默认本地所有Maven项目都共用一个本地仓库，本地仓库从中央仓库下载必要的jar包，以供各个本地项目调用
本机
本地仓库
ProjectA
ProjectB
ProjectN
远程中央仓库
-
Maven仓库分类：
-
本地仓库：存放从远程中央仓库下载的依赖组件
Windows默认地址：
C:\user\.m2\repositoryLinux默认地址：
~/.m2/repository-
远程中央仓库：由Apache官方维护的组件库，组件可升级
-
私有仓库：机构自己搭建的远程仓库（适用于本机构内部各个项目组适用）
-
中央仓库的镜像（第三方公共库）：比如国内阿里Maven镜像仓库
-
-
仓库中的文件
-
Maven 的插件
-
自己开发的项目的模块
-
第三方框架或工具的 jar 包
-
Maven中央仓库地址：http://mvnrepository.com/
2. Maven坐标
Maven通过坐标对jar包进行唯一标识。
-
坐标通过3个元素，
groupId、artifactId、version-
groupId：组织标识，一般为域名倒置 -
artifactId：项目名或模块名，是当前项目中的唯一标识 -
version：当前项目版本
-
不管是什么样的 jar 包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖，查询地址
3. Maven的安装和配置
-
安装
jdk环境：Maven运行需要依赖jdk -
官网下载Maven，将下载的Maven压缩包直接解压到本地磁盘
-
配置环境变量：
-
MAVEN_HOME：Maven解压文件路径 -
Path：
%MAVEN_HOME%/bin
-
-
测试是否安装成功：
mvn -v查询版本信息 -
本地仓库配置
-
Maven本地仓库默认地址是
C:\user\.m2\repository
为了节约C盘资源，最好改变Maven本地仓库地址
-
修改本地仓库地址：Maven安装目录——
conf文件夹——在settings.xml配置文件中重新指定本地地址
-
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<localRepository>E:\apache-maven-3.8.6\repository</localRepository>
-
远程仓库配置
Maven远程仓库默认地址为：http://my.repository.com/repo/path
-
修改远程仓库地址：Maven安装目录——
conf文件夹——在settings.xml配置文件中重新指定远程地址（国内阿里云镜像）
<!-- mirror | Specifies a repository mirror site to use instead of a given repository. The repository that | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used | for inheritance and direct lookup purposes, and must be unique across the set of mirrors. | --> <mirror> <id>nexus-aliyun</id> <mirrorOf>central</mirrorOf> <name>Nexus aliyun</name> <url>http://maven.aliyun.com/nexus/content/groups/public</url> </mirror>
4. Maven项目标准目录结构
一个Maven工程的目录结构，规范为下图所示：
A project
-
src-
main
-
java—— 存放项目的.java文件 -
resources —— 存放项目资源文件，如spring, hibernate配置文件
-
-
test
-
java—— 存放所有测试.java文件，如Junit测试类 -
resources —— 测试资源文件
-
-
-
target —— 目标文件输出位置例如
.class、.jar、.war文件 -
pom.xml—— Maven项目核心配置文件
必要
src
pom.xml
Project
main
java
target
test
resources
_java_
_resources_
手动创建一个最简易的Maven工程，方便理解底层原理
-
创建必要文件目录结构（如上图）
-
pom.xml文件：Maven核心配置文件。项目对象模型(Project Object Model ,
POM)：<project></project>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.neusoft</groupId>
<artifactId>hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<dependencies>
<!--这里添加项目依赖的jar包，例如：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
-->
</dependencies>
</project>
项目对象模型属性概述
-
modelVersion：Maven2.0版本以上必须这样写 -
groupId：组织标识，也是本地仓库中的路径
groupId分为三部分，每个部分以“.”相隔
第一部分是项目用途，比如用于商业的就是“com”，用于非盈利性质就是“org”
第二部分是公司名，比如“alibaba”，“jingdong”
第三部分是项目名
-
artifactId：项目或模块名称，是当前项目中的唯一标识 -
version：当前项目版本（snapshot：开发版；即不稳定版）
-
packaging：当前项目打包格式（jar、war、
pom）（默认jar） -
dependencies：配置项目以来的jar包
-
在
src/main/java文件夹中创建的com.neusoft.hello.Hello.java文件：
package com.neusoft.hello;
public class Hello{
public static void main(String[] args){
System.out.println("hello world!");
}
}
5. Maven命令总结
Maven 命令的格式为 mvn [plugin-name]:[goal-name]，可以接受的参数如下：
-
-D 指定参数，如 -Dmaven.test.skip=true 跳过单元测试；
-
-P 指定 Profile 配置，可以用于区分环境；
-
-e 显示maven运行出错的信息；
-
-o 离线执行命令,即不去远程仓库更新包；
-
-X 显示maven允许的debug信息；
-
-U 强制去远程更新snapshot的插件或依赖，默认每天只更新一次。
| 命令 | 说明 |
|---|---|
| mvn -help | 查看帮助 |
| mvn help:describe -Dplugin=help | 使用 help 插件的 describe 目标来输出 Maven Help 插件的信息 |
| mvn help:effective-pom | 看这个“有效的 (effective)”POM，它暴露了 Maven的默认设置，查看完整的pom信息 |
| mvn help:system | 从中央仓库下载文件至本地仓库 |
| mvn -e | 显示详细错误信息 |
| mvn validate | 验证工程是否正确，所有需要的资源是否可用 |
| mvn -v | 查看当前maven版本 |
| mvn archetype:generate | 反向生成 maven 项目骨架，建立目录结构，创建Maven项目 |
| mvn archetype:generate -DgroupId=otowa.user.dao -DartifactId=user-dao -Dversion=0.01-SNAPSHOT | 指定完只剩下确认步骤 指定 group： -DgroupId=packageName 指定 artifact：-DartifactId=projectName 指定 version：-Dversion=0.01-SNAPSHOT |
| mvn archetype:create -DgroupId=packageName -DartifactId=projectName | 创建Maven普通Java项目 |
| mvn archetype:create -DgroupId=packageName -DartifactId=webappName -DarchetypeArtifactId=maven-archetype-webapp | 创建Maven Web项目 创建web项目：-DarchetypeArtifactId=maven-archetype-webapp |
mvn idea:idea | 生成idea项目 |
| mvn clean compile | 编译源代码，生成class文件 |
| mvn -Dmaven.test.skip=true | 跳过单元测试，忽略测试文档编译 |
| mvn test-compile | 编译测试源代码 |
| mvn verify | 对集成测试结果进行任何检查 |
| mvn clean test | 执行单元测试，运行测试代码 |
| mvn test -skipping compile -skipping test-compile | 只测试而不编译，也不测试编译 |
| mvn integration-test | 将包处理和发布到一个能够进行集成测试的环境 在集成测试可以运行的环境中处理和发布包 |
| mvn clean package | 项目打包命令，将项目打包到target目录下 |
mvn -Dtest package / mvn clean package -DskipTests -Prelease | 组合使用goal命令，如只打包不测试 Maven打包跳过测试 |
mvn jar:jar / mvn source:jar-no-fork | 打成jar命令（只打jar包） |
| mvn clean install | 本地Repository中安装jar——打包到本地仓库，解决本地多个项目共用 |
| mvn install:install-file -DgroupId=packageName -DartifactId=projectName -Dversion=version -Dpackaging=jar -Dfile=path | 安装本地jar到本地仓库 |
| mvn source:jar | 生成源码jar包 |
| mvn clean | 清除项目，将项目根目录下的target目录删除 |
| mvn dependency:tree | 打印显示整个maven依赖树 |
| mvn dependency:sources | 打印显示出已解决依赖的列表 |
| mvn dependency:list | 查看当前项目已被解析的maven依赖列表 |
| mvn dependency:analyze | 查看依赖的工具 |
| mvn dependency:sources | 下载依赖包的源码 |
| mvn generate-sources | 产生应用需要的任何额外的源代码 |
| mvn site | 生成Maven项目相关信息的网站（用以生成HTML页面的模块等文档） |
| mvn clean deploy | 创建maven项目：mvn archetype:create 指定 group： -DgroupId=packageName部署到版本仓库 |
简单示例
-
编译：
mvn compile将
java文件编译成class文件，必须在项目目录下运行的命令E:\Hello>mvn compile
-
运行：
mvn exec命令执行main方法
E:\Hello>mvn exec:java -Dexec.mainClass="com.neusoft.hello.Hello"
-
单元测试：
mvn test执行
src/test/java目录下的单元测试类注意：单元测试类名规范：
XXTest.java，并且要在pom.xml中依赖junit包
辨析命令
-
mvn package与mvn install、mvn deploy：
-
package命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
-
install命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库
-
deploy命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
-
mvn package与mvn install：
-
mvn package：
1. 将项目打包（jar/war），将打包结果放到项目下的 target 目录下
-
mvn install：
1. 将项目打包（jar/war），将打包结果放到项目下的 target 目录下
2. 同时将上述打包结果放到本地仓库的相应目录中，供其他项目或模块引用
打包到本地仓库，如果没设置 Maven 本地仓库，一般在 用户/.m2 目录下
-
mvn jar:jar与mvn source:jar
-
.jar中是编译后的class文件，发布和使用的毫无疑问应该是.jar文件
-
source.jar中是java源文件，source.jar只是为了方便源码而存在的，没有其他作用
-
mvn verify与mvn test
-
test - 使用合适的单元测试框架测试编译的源代码。这些测试不应该要求打包或部署代码
-
verify - 对集成测试的结果进行任何检查，以确保满足质量标准
如果运行test，Maven 将执行validate、compile和test。基于此，verify包含test
verify 命令在执行验证之前按顺序执行每个默认生命周期阶段（验证、编译、打包等）。但是，如果有集成测试，这些测试也会被执行。在 verify 阶段可以进行一些额外的检查，例如如果您的代码是根据预定义的 checkstyle 规则编写的。
要运行单元测试，建议使用Surefire plugin。 Failsafe 用于集成测试。
业务逻辑
一般使用情况是：
-
首先通过
cvs或svn下载代码到本机 -
然后执行
mvn idea:idea生成idea项目文件，然后导入到idea； -
修改代码后执行
mvn compile或mvn test检验，也可以下载idea的maven插件。
参考资料：
6. Maven中的jdk版本设置
6.1. 局部配置jdk版本
针对具体某个项目进行配置，在当前项目的
pom.xml文件中添加properties元素
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<properties>
<!--or spring boot 中的简易写法-->
<properties>
<java.version>11</java.version>
<properties>
6.2. 全局配置jdk版本
打开
settings.xml配置文件，找到profiles这个标签，在这里添加如下代码：
<profile>
<id>jdk-11</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>11</jdk>
</activation>
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.compilerVersion>11</maven.compiler.compilerVersion>
</properties>
</profile>
………
</profiles>
7. Maven中的依赖
7.1. 依赖范围
Maven项目在不同的阶段引入到classpath中的依赖是不同的，常见依赖范围有以下四种：
-
compile：编译依赖范围，在编译，测试，运行时都需要。
-
test：测试依赖范围，测试时需要。编译和运行不需要
-
runtime：运行时依赖范围，测试和运行时需要。编译不需要。（通常由compile替代）
-
provided：已提供依赖范围，编译和测试时需要。运行时不需要。
| Scope取值 | 编译范围(对于主代码classpath有效) | 测试范围(对于测试代码classpath有效) | 运行范围(被打包，对于运行时classpath有效) | 例子 |
|---|---|---|---|---|
| compile(默认) | Y | Y | Y | log4j |
| test | - | Y | - | junit |
| provided | Y | Y | - | servlet-api |
| runtime | - | Y | Y | JDBC Driver |
-
在Maven中，使用scope标签来表示依赖范围(
pom.xml)。
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>
7.2. 传递依赖
在Maven的pom.xml中书写的jar包
如果存在直接依赖关系，或是传递依赖关系，那么Maven也会将所依赖的jar包一同导入
比如：
A->B：A包依赖B包，这是直接依赖
A->B->C：A包依赖B包，B包又依赖C包，这是传递依赖依赖的传递性
A 依赖 B，B 依赖 C，A 能否使用 C 呢？那要看 B 依赖 C 的范围是不是 compile，如果是则可用，否则不可用
7.3. 排除依赖
如果我们在当前工程中引入了一个依赖是 A，而 A 又依赖了 B，那么 Maven 会自动将 A 依赖的 B 引入当前工程；
但是个别情况下 B 有可能是一个不稳定版，或对当前工程有不良影响。这时我们可以在引入 A 的时候将 B 排除
<dependency>
<groupId>net.lazyegg.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
<exclusions> <!--排除-->
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
7.4. 依赖原则：
解决 jar 包冲突
-
路径最短者优先
-
路径相同时先声明者优先
IDEA插件：Maven Helper 方便解决jar包冲突
第一原则：最短路径优先原则
“最短路径优先”意味着项目依赖关系树中路径最短的版本会被使用。
例如，假设A、B、C之间的依赖关系是A—＞B—＞C—＞D（2.0）和A—＞E—＞（D1.0），那么D（1.0）会被使用，因为A通过E到D的路径更短。
第二原则：最先声明原则
依赖路径长度是一样的的时候，第一原则不能解决所有问题，比如这样的依赖关系：A—＞B—＞Y（1.0），A—＞C—＞Y（2.0），Y（1.0）和Y（2.0）的依赖路径长度是一样的，都为2。
在maven2.0.8及之前的版本中，先后是不确定的，但是maven2.0.9开始，为了尽可能避免构建的不确定性，maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用。顺序最靠前的那个依赖优胜。
8. Maven的继承
-
为什么需要继承机制？
由于非 compile 范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置
-
创建父工程：创建父工程和创建一般的 Java 工程操作一致，唯一需要注意的是：打包方式处要设置为 pom
-
在子工程中引用父工程 ，从当前目录到父项目的 pom.xml 文件的相对路径
<parent>
<groupId>com.starfish.maven</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!-- 以当前文件为基准的父工程pom.xml文件的相对路径 -->
<relativePath>../Parent/pom.xml</relativePath>
</parent>
此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除。
-
在父工程中管理依赖：将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
在子项目中重新指定需要的依赖，删除范围和版本号
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
9. Maven的聚合
-
前提：继承。聚合包含了继承的特性。
-
聚合时多个项目的本质还是一个项目。这些项目被一个大的父项目包含。且这时父项目类型为pom类型。同时在父项目的pom.xml中出现＜modules＞表示包含的所有子模块。
在创建聚合工程的过程中，总的工程必须是一个POM工程（Maven Project）（聚合项目必须是一个pom类型的项目，jar项目war项目是没有办法做聚合工程的），各子模块可以是任意类型模块（Maven Module）。
-
-
为什么要使用聚合？
当我们开发的工程拥有2个以上模块的时候，每个模块都是一个独立的功能集合。比如某大学系统中拥有搜索平台，学习平台，考试平台等。开发的时候每个平台都可以独立编译，测试，运行。这个时候我们就需要一个聚合工程。
将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行 clean 操作
而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作
-
如何配置聚合？
在总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可
<!-- 配置聚合 -->
<modules>
<!-- 指定各个子工程的相对路径 -->
<module>starfish-learn-grpc</module>
<module>starfish-learn-kafka</module>
<module>starfish-web-demo</module>
</modules>
#Maven的文件目录结构
-
bin binary二进制文件的简称，里面存放的一般是可执行的二进制文件
-
boot 里面存放启动目录的核心文件
-
conf 里面存放配置文件，包含核心全局配置文件settings.xml
-
lib 里面存放类库或者资源文件
参考资料合集
-
面向更新版本后丢失的jar包
扫一扫
1617
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
