Maven开发实战(三)

导言:生产环境下开发不再是一个项目一个工程,而是每一个模块创建一个工程,而多个模块整合在一起就需要

使用到像 Maven 这样的构建工具。

今天的主题是:How? 怎样使用Maven
更多教程笔记源码请扫下方二维码获取

Maven 核心程序中仅仅定义了抽象的生命周期,而具体的操作则是由 Maven 插件来完成的。可是

Maven 的插件并不包含在 Maven 的核心程序中,在首次使用时需要联网下载。

下载得到的插件会被保存到本地仓库中。本地仓库默认的位置是:~\.m2\repository

如果不能联网可以使用我们提供的 RepMaven.zip 解压得到。具体操作参见“Maven 操作指南.txt

约定的目录结构

约定的目录结构对于 Maven 实现自动化构建而言是必不可少的一环,就拿自动编译来说,Maven 必须

能找到 Java 源文件,下一步才能编译,而编译之后也必须有一个准确的位置保持编译得到的字节码文件。

我们在开发中如果需要让第三方工具或框架知道我们自己创建的资源在哪,那么基本上就是两种方式:

通过配置的形式明确告诉它

基于第三方工具或框架的约定

Maven 对工程目录结构的要求就属于后面的一种。


现在 JavaEE 开发领域普遍认同一个观点:约定>配置>编码。意思就是能用配置解决的问题就不编码,

能基于约定的就不进行配置。而 Maven 正是因为指定了特定文件保存的目录才能够对我们的 Java 工程进行

自动化构建。

3.1 POM

Project Object Model:项目对象模型。将 Java 工程的相关信息封装为对象作为便于操作和管理的模型

Maven 工程的核心配置。可以说学习 Maven 就是学习 pom.xml 文件中的配置。

坐标

3.2 几何中的坐标

[1]在一个平面中使用 xy 两个向量可以唯一的确定平面中的一个点。

[2]在空间中使用 xyz 三个向量可以唯一的确定空间中的一个点。

3.3 Maven 的坐标

使用如下三个向量在 Maven 的仓库中唯一的确定一个 Maven 工程。

[1]groupid:公司或组织的域名倒序+当前项目名称

[2]artifactId:当前项目的模块名称

[3]version:当前模块的版本

<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>

3.4 如何通过坐标到仓库中查找 jar 包?

[1] gav 三个向量连起来

com.atguigu.maven+Hello+0.0.1-SNAPSHOT

[2]以连起来的字符串作为目录结构到仓库中查找

com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

注意:我们自己的 Maven 工程必须执行安装操作才会进入仓库。安装的命令是:mvn install

4 依赖

Maven 中最关键的部分,我们使用 Maven 最主要的就是使用它的依赖管理功能。要理解和掌握 Maven

的依赖管理,我们只需要解决一下几个问题:

依赖的目的是什么

 A jar 包用到了 B jar 包中的某些类时,A 就对 B 产生了依赖,这是概念上的描述。那么如何在项目

中以依赖的方式引入一个我们需要的 jar 包呢?

答案非常简单,就是使用 dependency 标签指定被依赖 jar 包的坐标就可以了。

<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>

依赖的范围

大家注意到上面的依赖信息中除了目标 jar 包的坐标还有一个 scope 设置,这是依赖的范围。依赖的范

围有几个可选值,我们用得到的是:compiletestprovided 三个。

[1]从项目结构角度理解 compile  test 的区别

结合具体例子:对于 HelloFriend 来说,Hello 就是服务于主程序的,junit 是服务于测试程序的。

HelloFriend 主程序需要 Hello 是非常明显的,测试程序由于要调用主程序所以也需要 Hello,所以

compile 范围依赖对主程序和测试程序都应该有效。

HelloFriend 的测试程序部分需要 junit 也是非常明显的,而主程序是不需要的,所以 test 范围依赖

仅仅对于主程序有效。

[2]从开发和运行这两个不同阶段理解 compile  provided 的区别

[3]有效性总结

compile

test

provided

主程序

×

测试程序

参与部署

×

×







依赖的传递性

A 依赖 BB 依赖 CA 能否使用 C 呢?那要看 B 依赖 C 的范围是不是 compile,如果是则可用,否则不可用。

Maven 工程

依赖范围

 A 的可见性

A

B

C

compile

D

test

×

E

provided

×



依赖的排除

如果我们在当前工程中引入了一个依赖是 A,而 A 又依赖了 B,那么 Maven 会自动将 A 依赖的 B 引入当

前工程,但是个别情况下 B 有可能是一个不稳定版,或对当前工程有不良影响。这时我们可以在引入 A 的时

候将 B 排除。【未完。。。。。】


更多教程资料或者项目请关注:



猜你喜欢

转载自blog.csdn.net/cadn_jueying/article/details/80593400