---
区分项目的不同组成部分
net.sf.json-lib json-lib 2.2.2 jdk15-javadoc
构件名与坐标是对应的,一般规则是:artifactId-version[-classifier].packaging。
#### 依赖声明
... ...
* `groupId`、`artifactId`、`version`:依赖的基本坐标。
* `type`:依赖的类型,对应项目对应的 packaging,一般不必声明。
* `scope`:依赖的范围,后面详解。
* `optional`:标记依赖是否可选。
* `exclusions`:用来排除传递性依赖。
#### 依赖范围
* `compile`:编译依赖范围
如果没有指定,默认使用该依赖范围。对于编译、测试、运行三种 classpath 都有效。如:spring-core。
* `test`:测试依赖范围
只对于测试 classpath 有效,只需要在编译测试及运行测试才需要,在打包的时候不会打进去。如:JUnit。
* `provided`:已提供依赖范围
对于编译和测试 classpath 有效,但运行时无效。如:servlet-api 编译和测试项目的时候都需要,但在实际运行中,容器已经提供,不需要 maven 重复的引用。
* `runtime`:运行时依赖范围
对于测试和运行的 classpath 有效,但在编译主代码时无效。如:JDBC 驱动的实现包。只有在执行测试或者运行项目时,才需要具体的 JDBC 驱动。
* `system`:系统依赖范围
与 provided 依赖范围完全一致,但是使用该范围时必须通过 systemPath 元素显式地指定依赖文件的路径。由于此类依赖不是通过 maven 仓库解析的,而且往往与本机系统绑定,可能造成构建不可移植,因此应该谨慎使用。systemPath 元素可以引用环境变量,如:
javax.sql jdbc-stdxt 2.0 system ${java.home}/lib/rt.jar
* import:导入依赖范围
只在 dependencyManagement 标签中生效,导入已经定义好的 pom 文件中 dependencyManagement 节点内容
org.springframework spring-framework-bom 4.3.16.RELEASE pom import
#### 依赖机制与特性
依赖传递
* A->B(compile):第一直接依赖
* B->C(compile):第二直接依赖
* A->C(compile):传递性依赖
当在A中配置
com.B B 1.0
则会自动导入 C 包。
**传递性依赖的范围如下图所示:**
![图片](https://img-blog.csdnimg.cn/img_convert/7d369ba125cb059630bcf508ea88ea37.png)
依赖调解
当传递性依赖出现问题时,能够清楚地知道该传递性依赖是从哪条依赖路径中引入的。
一、路径最近者优先原则
* A->B->C->X(1.0)
* A->D->X(2.0)
由于只能导入一个版本的包,按照最短路径选择导入 X(2.0)
二、第一声明者优先原则
* A->B->Y(1.0)
* A->C->Y(2.0)
此时由于依赖路径长度一致,按照第一声明者优先原则。在路径长度一致的前提下,如果 B 依赖在 POM 文件中声明顺序在 C 依赖之前,那么 Y(1.0) 则会被引入。如下依赖可用于测试:
org.apache.httpcomponents httpclient 4.4.1 commons-codec commons-codec
org.apache.poi
poi
3.9
commons-codec
commons-codec
commons-codec
commons-codec
1.10
这里有一点需要特别注意,看如下依赖:
commons-codec commons-codec 1.11
commons-codec
commons-codec
1.10
按照两原则,期望得到的结果应该是 1.11 版本的构建将被依赖。但实际结果却依赖了 1.10 版本。what!这不是违反了 maven 依赖调解的最先定义原则?
其实这个是 dependency 插件的功能,默认采用的是复写的策略,当构建声明处于同一 pom 中,且 groupid 和 artifactId 一致时,以最新声明为准,后面的覆盖前面的。
注意这里没涉及到依赖调解的功能。我的理解是依赖调解只发生于构建来自不同 pom 时,而此时构建声明处于同一 pom,故不会触发依赖调解。
可选依赖
A->B、B->X(可选)、B->Y(可选)。
项目 A 依赖于项目 B,项目 B 依赖于项目 X 和 Y。
理论上项目 A 中,会把 B、X、Y 项目都依赖进来。
但是 X、Y 两个依赖对于 B 来讲可能是互斥的,如 B 是数据库隔离包,支持多种数据库 MySQL、Oracle,在构建 B 项目时,需要这两种数据库的支持,但在使用这个工具包时,只会依赖一个数据库。
此时就需要在 B 项目 pom 文件中将 X、Y 声明为可选依赖,如下:
com.X X 1.0 true com.Y Y 1.0 true
使用 optionnal 元素标识以后,只会对当前项目 B 产生影响,当其他的项目依赖 B 项目时,这两个依赖都不会被传递。
项目 A 依赖于项目 B,如果实际应用数据库是 X, 则在 A 的 pom 中就需要显式地声明 X 依赖。
### 仓库
仓库分类:包括本地仓库和远程仓库。其中远程仓库包括:私服和中央仓库。搜索构建的顺序:
* 本地仓库
* maven settings profile 中的 repository;
* pom.xml 中 profile 中定义的repository;
* pom.xml 中 repositorys (按定义顺序找);
* maven settings mirror;
* central 中央仓库;
### 生命周期
Maven 的生命周期是为了对所有构建过程进行的抽象和统一,其中包含项目的`清理`、`初始化`、`编译`、`测试`、`打包`、`集成测试`、`验证`、`部署`和`站点`生成等几乎所有的构建步骤。
Maven 的生命周期是抽象的,本身是不做任何实际的工作。实际的任务都交给插件来完成。
意味着 Maven 只在父类中定义了算法的整体结构,子类通过重写父类的方法,来控制实际行为(设计模式中的模板方法 Template Method)。伪代码如下:
public abstract class AbstractBuilder {
public void build() {
init();
compile();
test();
package();
integrationTest();
deploy();
}
protected abstract void init();
protected abstract void compile();
protected abstract void test();
protected abstract void package();
protected abstract void integrationTest();
protected abstract void deploy();
}
#### 三套生命周期
Maven 的生命周期并不是一个整体,Maven 拥有三套相互独立的生命周期,它们分别为 clean、default 和 site。
* `clean` 生命周期的目的是清理项目;
* `default` 生命周期的目的是构建项目;
* `site` 生命周期的目的是建立项目站点;
#### 单个生命周期执行顺序
每个生命周期包含一些阶段(phase),这些阶段是有顺序的,并且后面的阶段依赖于前面的阶段。
以 clean 生命周期为例,它包含的阶段有 pre-clean、clean和post-clean。当调用 pre-clean 时,只有 pre-clean 阶段得以执行;
当调用 clean 的时候,pre-clean和clean阶段会得以顺序执行,以此类推。
#### 各个生命周期之间的关系
三套生命周期本身是相互独立的,用户可以仅调用 clean 生命周期的某个阶段,或者仅仅调用 default 生命周期的某个阶段,而不会对其他生命周期产生任何影响。
例如,当用户调用 clean 生命周期的 clean 阶段的时候,不会触发 default 生命周期的任何阶段,反之亦然。
#### 生命周期各个阶段详解
clean
| 生命周期阶段 | 描述 |
| --- | --- |
| pre-clean | 执行一些清理前需要完成的工作。 |
| clean | 清理上一次构建生成的文件。 |
| post-clean | 执行一些清理后需要完成的工作。 |
default
包含 23 个阶段,此处只介绍重点步骤,如下表:
| 生命周期阶段 | 描述 |
| --- | --- |
| validate | 检查工程配置是否正确,完成构建过程的所有必要信息是否能够获取到。 |
| initialize | 初始化构建状态,例如设置属性。 |
| generate-sources | |
| process-sources | 处理项目资源文件,处理项目主资源文件。一般来说,是对src/main/resources目录的内容进行变量替换等工作后,复制到项目输出的主classpath目录中。 |
| generate-resources | |
| process-resources | |
| compile | 编译项目的主源码。一般来说,是编译src/main/java目录下的Java文件至项目输出的主classpath目录中。 |
| process-classes | 处理编译生成的文件,例如 Java Class 字节码的加强和优化。 |
| generate-test-sources | |
| process-test-sources | 处理项目测试资源文件。一般来说,是对src/test/resources目录的内容进行变量替换等工作后,复制到项目输出的测试classpath目录中。 |
| test-compile | 编译项目的测试代码。一般来说,是编译src/test/java目录下的Java文件至项目输出的测试classpath目录中。 |
| process-test-classes | |
| test | 使用适当的单元测试框架(例如JUnit)运行测试。 |
| prepare-package | 在真正打包之前,为准备打包执行任何必要的操作。 |
| package | 获取编译后的代码,并按照可发布的格式进行打包,例如 JAR、WAR 或者 EAR 文件。 |
| pre-integration-test | 在集成测试执行之前,执行所需的操作。例如,设置所需的环境变量。 |
| integration-test | 处理和部署必须的工程包到集成测试能够运行的环境中。 |
| post-integration-test | 在集成测试被执行后执行必要的操作。例如,清理环境。 |
| verify | 运行检查操作来验证工程包是有效的,并满足质量要求。 |
| install | 安装工程包到本地仓库中,该仓库可以作为本地其他工程的依赖。 |
| deploy | 拷贝最终的工程包到远程仓库中,以共享给其他开发人员和工程。 |
site
| 生命周期阶段 | 描述 |
| --- | --- |
| pre-site | 执行一些在生成项目站点之前需要完成的工作。 |
| site | 生成项目站点文档。 |
| post-site | 执行一些在生成项目站点之后需要完成的工作。 |
| site-deploy | 将生成的项目站点发布到服务器上。 |
### 插件
Maven 三套生命周期定义各个阶段不做任何实际工作,实际工作都是由插件来完成的,每个生命周期阶段都是由插件的目标来完成。在 pom 文件中声明如下(打包源码文件插件):
org.apache.maven.plugins maven-source-plugin 2.1.1 attach-sources verify jar-no-fork
#### 插件目标
一个插件有可能有多个功能、每个功能就是一个目标。比如 maven-dependency-plugin 有十多个目标,每个目标对应了一个功能。
插件的目标为 dependency:analyze、dependency:tree和dependency:list。
通用写法:冒号前面是插件前缀,冒号后面是插件的目标。比如 compiler:compile。
![图片](https://img-blog.csdnimg.cn/img_convert/33775856807499ebd17e5e1dd4379bf2.png)
#### 插件绑定
![](https://img-blog.csdnimg.cn/4198150b3424472ab2f8e757bd42aac4.gif)
#### 内置绑定
为实现快速构建,Maven 有一套内置的插件绑定。三套生命周期的插件绑定具体如下(其实是各个生命周期阶段与插件的目标的绑定)。
其中 default 生命周期的构建方式会其打包类型有关、打包类型在POM中 packaging 指定。一般有 jar、war 两种类型。下面是默认绑定插件与生命周期关系图:
![图片](https://img-blog.csdnimg.cn/img_convert/9fce95f5e69f3defbf1c15e47a6f5e68.png)
#### 自定义绑定
自定义绑定允许我们自己掌控插件目标与生命周期的结合。以生成项目主代码的源码 jar 为例。
使用到的插件和它的目标为:maven-source-plugin:jar-no-fork。将其绑定到 default 生命周期阶段 verify 上(可以任意指定三套生命周期的任意阶段)。
org.apache.maven.plugins maven-source-plugin 2.1.1 attach-sources
verify
jar-no-fork
#### 插件配置
* 使用命令行配置
在 maven 命令中加入 -D 参数,并伴随一个参数键=参数值的形式,来配置插件目标参数。
如:maven-surefire-plugin 插件提供一个 maven.test.skip 参数,当值为 true 时会跳过执行测试:
– 对比 mvn install
mvn install –Dmaven.test.skip=true
* 使用 pom 全局配置
在声明插件的时候,对插件进行一个全局配置,后面所有使用该插件的都要遵循这个配置。比如指定 maven-compile-plugin 编译 1.7 版本的源文件:
### 一、网安学习成长路线图
网安所有方向的技术点做的整理,形成各个领域的知识点汇总,它的用处就在于,你可以按照上面的知识点去找对应的学习资源,保证自己学得较为全面。
![在这里插入图片描述](https://img-blog.csdnimg.cn/aa7be04dc8684d7ea43acc0151aebbf1.png)
### 二、网安视频合集
观看零基础学习视频,看视频学习是最快捷也是最有效果的方式,跟着视频中老师的思路,从基础到深入,还是很容易入门的。
![在这里插入图片描述](https://img-blog.csdnimg.cn/f0aeee2eec7a48f4ad7d083932cb095d.png)
### 三、精品网安学习书籍
当我学到一定基础,有自己的理解能力的时候,会去阅读一些前辈整理的书籍或者手写的笔记资料,这些笔记详细记载了他们对一些技术点的理解,这些理解是比较独到,可以学到不一样的思路。
![在这里插入图片描述](https://img-blog.csdnimg.cn/078ea1d4cda342f496f9276a4cda5fcf.png)
### 四、网络安全源码合集+工具包
光学理论是没用的,要学会跟着一起敲,要动手实操,才能将自己的所学运用到实际当中去,这时候可以搞点实战案例来学习。
![在这里插入图片描述](https://img-blog.csdnimg.cn/e54c0bac8f3049928b488dc1e5080fc5.png)
### 五、网络安全面试题
最后就是大家最关心的网络安全面试题板块
![在这里插入图片描述](https://img-blog.csdnimg.cn/15c1192cad414044b4dd41f3df44433d.png)![在这里插入图片描述](https://img-blog.csdnimg.cn/b07abbfab1fd4edc800d7db3eabb956e.png)