目录
一、简介
随着我们使用越来越多的框架,或者框架封装程度越来越高,项目中使用的jar包也越来越多。我们利用maven可以方便地对依赖进行管理。
另外,maven可以作为构建管理工具。当我们使用 IDEA 在本地进行开发时,构建是 IDEA 替我们做的。如果我们要把代码部署到服务器中,就可以用maven完成打包操作。

二、POM文件的基本结构
pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置,各个配置有什么用。
<!--
当前Maven工程的坐标
groupId:公司或组织的 id
artifactId:一个项目或者是项目中的一个模块的 id
version:版本号
-->
<groupId>com.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 当前Maven工程的打包方式,可选值有下面三种: -->
<!-- jar:表示这个工程是一个Java工程 -->
<!-- war:表示这个工程是一个Web工程 -->
<!-- pom:表示这个工程是“管理其他工程”的工程 -->
<packaging>jar</packaging>
<name>pro01-maven-java</name>
<url>http://maven.apache.org</url>
<properties>
<!-- 工程构建过程中读取源码时使用的字符集 -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<!-- 当前工程所依赖的jar包 -->
<dependencies>
<!-- 使用dependency配置一个具体的依赖 -->
<dependency>
<!-- 在dependency标签内使用具体的坐标依赖我们需要的一个jar包 -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<!-- scope标签配置依赖的范围 -->
<scope>test</scope>
</dependency>
</dependencies>
三、依赖的范围
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<!-- scope标签配置依赖的范围 -->
<scope>test</scope>
<scope>标签有如下取值:
compile/test/provided/system/runtime/import
compile:通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。这个也是默认值。
test:测试过程中使用的 jar 包,以 test 范围依赖进来。比如 junit。
provided:在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包,就是避免和服务器上已有的同类 jar 包产生冲突,同时减轻服务器的负担。说白了就是:“服务器上已经有了,你就别带啦!”
四、依赖的传递
在 A 依赖 B,B 依赖 C 的前提下,C 是否能够传递到 A,取决于 B 依赖 C 时使用的依赖范围。
- B 依赖 C 时使用 compile 范围:可以传递
- B 依赖 C 时使用 test 或 provided 范围:不能传递,所以需要这样的 jar 包时,就必须在需要的地方明确配置依赖才可以。

比如这样的结构,parent依赖son1,son1依赖son2.

五、依赖的排除
当 A 依赖 B,B 依赖 C 而且 C 可以传递到 A 的时候,A 不想要 C,需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。

<dependency>
<groupId>com.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
<!-- 使用excludes标签配置依赖的排除 -->
<exclusions>
<!-- 在exclude标签中配置一个具体的排除 -->
<exclusion>
<!-- 指定要排除的依赖的坐标(不需要写version) -->
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
六、继承与聚合
聚合就是使用一个“总工程”将各个“模块工程”汇集起来,作为一个整体对应完整的项目
Maven工程之间,A 工程继承 B 工程
B 工程:父工程
A 工程:子工程
本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。我们可以在父工程中统一管理项目中的依赖信息,具体来说是管理依赖信息的版本。
从继承关系角度来看:
- 父工程
- 子工程
从聚合关系角度来看:
- 总工程
- 模块工程
它的背景是:
- 对一个比较大型的项目进行了模块拆分。
- 一个 project 下面,创建了很多个 module。
- 每一个 module 都需要配置自己的依赖信息。
它背后的需求是:
- 在每一个 module 中各自维护各自的依赖信息很容易发生出入,不易统一管理。
- 使用同一个框架内的不同 jar 包,它们应该是同一个版本,所以整个项目中使用的框架版本需要统一。
- 使用框架时所需要的 jar 包组合(或者说依赖信息组合)需要经过长期摸索和反复调试,最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。
通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包;又能够将以往的经验沉淀下来,节约时间和精力。
注意:父工程的打包方式必须为pom
<!-- 当前工程作为父工程,它要去管理子工程,所以打包方式必须是 pom -->
<!--只有打包方式为 pom 的 Maven 工程能够管理其他 Maven 工程-->
<!--打包方式为 pom 的 Maven 工程中不写业务代码,它是专门管理其他 Maven 工程的工程-->
<packaging>pom</packaging>
6.1 父工程的一些参数
modules 和 module 标签是聚合功能的配置,这个父工程包含3个子工程
<modules>
<module>maven-module1</module>
<module>maven-module2</module>
<module>maven-module3</module>
</modules>
父工程统一管理依赖:
<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
父工程自定义属性:
<!-- 通过自定义属性,统一指定Spring的版本 -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- 自定义标签,维护Spring版本数据 -->
<spring.version>4.3.6.RELEASE</spring.version>
</properties>
设置这个属性就可以动态地管理依赖的版本了,那么依赖的版本号可以这样表示:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
6.2 子工程的一些参数
<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
<!-- 父工程的坐标 -->
<groupId>com.maven</groupId>
<artifactId>maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致,那么可以省略 -->
<!-- <groupId>com.maven</groupId> -->
<artifactId>maven-module1</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->
在子工程中引用被父工程管理的依赖:
<!-- 子工程引用父工程中的依赖信息时,可以省略版本号!!! -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
</dependency>
</dependencies>
七、idea构建maven工程
7.1 创建一个maven工程/父工程
新建工程->选择maven->next->设置坐标(可选)->完成


7.2 创建一个maven子工程
在父工程上点击右键->new->module->maven->next->选择Parent->完成

这时parent 和 son 就是父子工程的关系,在父工程的pom.xml中:
<modules>
<module>maven-son</module>
</modules>
在子工程的pom.xml中:
<parent>
<artifactId>maven-parent</artifactId>
<groupId>com.maven</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
7.3 创建依赖关系
假如一个工程要引用另一个工程的依赖,就要在其pom.xml文件中加<dependency>:
<--! 假如是parent工程要引用son工程的依赖 -->
<dependency>
<groupId>com.maven</groupId>
<artifactId>maven-son</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
本文详细介绍了Maven在项目管理中的核心概念,包括POM文件的基本结构、依赖范围、依赖传递、依赖排除、继承与聚合。重点讲解了如何通过父工程管理子工程的依赖版本,以及在IntelliJ IDEA中创建和配置Maven工程的步骤。此外,还讨论了依赖范围如compile、test、provided等的区别,并解释了如何排除不必要的依赖。
4万+

被折叠的 条评论
为什么被折叠?



