先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新网络安全全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上网络安全知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
- A->B(compile):第一直接依赖
- B->C(compile):第二直接依赖
- A->C(compile):传递性依赖
当在A中配置
<dependency>
<groupId>com.B</groupId>
<artifactId>B</artifactId>
<version>1.0</version>
</dependency>
则会自动导入 C 包。
传递性依赖的范围如下图所示:
依赖调解
当传递性依赖出现问题时,能够清楚地知道该传递性依赖是从哪条依赖路径中引入的。
一、路径最近者优先原则
- 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) 则会被引入。如下依赖可用于测试:
<dependencies>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.4.1</version>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>3.9</version>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.10</version>
</dependency>
</dependencies>
这里有一点需要特别注意,看如下依赖:
<dependencies>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.11</version>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.10</version>
</dependency>
</dependencies>
按照两原则,期望得到的结果应该是 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 声明为可选依赖,如下:
<dependency>
<groupId>com.X</groupId>
<artifactId>X</artifactId>
<version>1.0</version>
<optionnal>true</optionnal>
</dependency>
<dependency>
<groupId>com.Y</groupId>
<artifactId>Y</artifactId>
<version>1.0</version>
<optionnal>true</optionnal>
</dependency>
使用 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 文件中声明如下(打包源码文件插件):
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
插件目标
一个插件有可能有多个功能、每个功能就是一个目标。比如 maven-dependency-plugin 有十多个目标,每个目标对应了一个功能。
插件的目标为 dependency:analyze、dependency:tree和dependency:list。
通用写法:冒号前面是插件前缀,冒号后面是插件的目标。比如 compiler:compile。
插件绑定
内置绑定
为实现快速构建,Maven 有一套内置的插件绑定。三套生命周期的插件绑定具体如下(其实是各个生命周期阶段与插件的目标的绑定)。
其中 default 生命周期的构建方式会其打包类型有关、打包类型在POM中 packaging 指定。一般有 jar、war 两种类型。下面是默认绑定插件与生命周期关系图:
自定义绑定
自定义绑定允许我们自己掌控插件目标与生命周期的结合。以生成项目主代码的源码 jar 为例。
使用到的插件和它的目标为:maven-source-plugin:jar-no-fork。将其绑定到 default 生命周期阶段 verify 上(可以任意指定三套生命周期的任意阶段)。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>attach-sources</id>
<!-- 指定作用在生命周期的哪个阶段 -->
<phase>verify</phase>
<goals>
<!-- 指定执行绑定插件的哪些目标 -->
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
插件配置
- 使用命令行配置
在 maven 命令中加入 -D 参数,并伴随一个参数键=参数值的形式,来配置插件目标参数。
如:maven-surefire-plugin 插件提供一个 maven.test.skip 参数,当值为 true 时会跳过执行测试:
-- 对比 mvn install
mvn install –Dmaven.test.skip=true
- 使用 pom 全局配置
在声明插件的时候,对插件进行一个全局配置,后面所有使用该插件的都要遵循这个配置。比如指定 maven-compile-plugin 编译 1.7 版本的源文件:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<fork>true</fork>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
聚合与继承
聚合
:为了一次构建多个项目模块,就需要对多个项目模块进行聚合
<modules>
<module>模块一</module>
<module>模块二</module>
<module>模块三</module>
</modules>
继承
:为了消除重复,把很多相同的配置提取出来,例如:dependency、grouptId,version 等
<parent>
<groupId>com.xxxx.maven</groupId>
<artifactId>parent-project</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../ParentProject/pom.xml</relativePath>
</parent>
以下的元素是可以被继承的:
- groupId,项目组ID;
- version,项目版本;
- description,项目描述信息;
- organazation,项目的组织信息;
- inceptionYear,项目的创始年份;
- developers,项目开发者信息;
- contributors,项目的贡献者信息;
- distributionManagement,项目的部署信息;
- issueManagement,项目的缺陷跟踪系统信息;
- ciManagement,项目的持续集成系统信息;
- scm,项目的版本控制系统信息;
- mailingLists,项目的邮件列表信息;
- properties,自定义的Maven属性;
- dependencies,项目的依赖配置;
- dependencyManagement,项目的依赖管理配置;
- repositories,项目的仓库配置;
- build,包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等;
- reporting,包括项目的报告输出目录配置、报告插件配置。
注意下面的元素,这些都是不能被继承
的:
- artifactId
- name
- prerequisites
聚合与继承之间的关系
- 两者共同点为,打方式必须都是 pom
- 在实际的项目中,一个 pom 既是聚合 pom 又是父 pom
注
:父 pom 中使用 dependencies 引入的依赖也会被子 pom 继承,所以不要将过多的实际依赖放在父 pom,父 pom 只用于管理,使用 dependencyManagement 标签。
灵活构建
使用属性、 resources 插件资源过滤功能(filter)和 Maven 的 profile 功能,实现环境的灵活切换
属性
通过 properties 元素用户可以自定义一个或者多个 Maven 属性,然后在 pom 其他的地方使用 ${属性名} 的方式引用该属性,这种方式最大意义在于消除重复。
一、内置属性
${basedir}
表示项目根目录,即包含 pom.xml 文件的目录${version}
等同于 或者{pom.version} 表示项目版本
二、POM 属性
所有 pom 中的元素都可以用 project. 例如 ${project.artifactId} 对应了 < project>元素的值。常用的 POM 属性包括:
${project.build.sourceDirectory}
: 项目的主源码目录,默认为 src/main/java/.${project.build.testSourceDirectory}
: 项目的测试源码目录,默认为 /src/test/java/.${project.build.directory}
: 项目构建输出目录,默认为 target/.${project.build.outputDirectory}
: 项目主代码编译输出目录,默认为 target/classes/.
写在最后
在结束之际,我想重申的是,学习并非如攀登险峻高峰,而是如滴水穿石般的持久累积。尤其当我们步入工作岗位之后,持之以恒的学习变得愈发不易,如同在茫茫大海中独自划舟,稍有松懈便可能被巨浪吞噬。然而,对于我们程序员而言,学习是生存之本,是我们在激烈市场竞争中立于不败之地的关键。一旦停止学习,我们便如同逆水行舟,不进则退,终将被时代的洪流所淘汰。因此,不断汲取新知识,不仅是对自己的提升,更是对自己的一份珍贵投资。让我们不断磨砺自己,与时代共同进步,书写属于我们的辉煌篇章。
需要完整版PDF学习资源私我
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
outputDirectory}` : 项目主代码编译输出目录,默认为 target/classes/.
写在最后
在结束之际,我想重申的是,学习并非如攀登险峻高峰,而是如滴水穿石般的持久累积。尤其当我们步入工作岗位之后,持之以恒的学习变得愈发不易,如同在茫茫大海中独自划舟,稍有松懈便可能被巨浪吞噬。然而,对于我们程序员而言,学习是生存之本,是我们在激烈市场竞争中立于不败之地的关键。一旦停止学习,我们便如同逆水行舟,不进则退,终将被时代的洪流所淘汰。因此,不断汲取新知识,不仅是对自己的提升,更是对自己的一份珍贵投资。让我们不断磨砺自己,与时代共同进步,书写属于我们的辉煌篇章。
需要完整版PDF学习资源私我
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!