Maven环境下构建多模块项目

Maven环境下构建多模块项目
使用maven 提供的多模块构建的特性完成maven 环境下多个模块
的项目的管理与构建。
1. 创建 maven_parent 项目

1.选择 File —> Settings —> Project

2. 设置 GroupId 和 ArtifactId

3. 设置项目名称及工作空间

 2. 创建 maven_dao项目

1. 选择项目maven_parent，右键选择 New ，选择Module

2. 选择Maven项目的模板（普通 Java 项目）

3. 设置子模块的的 ArtifactId

4. 设置Maven的配置

5. 设置子模块的名称及存放位置

  3. 创建 maven_service项目

创建 maven_service 模块的步骤与 maven_dao模块一致

 4 .建 maven_controller 模块

创建 maven_service 模块的步骤与 maven_dao模块基本一致，只
需要将第一步选择Maven模板设置为web项目即可。（模板类型：
maven-archetype-webapp）

 修改模块的配置
设置 JDK 版本
单元测试 JUnit版本
删除多余的配置

===========================================、

配置依赖

在 Maven 中，可以使用 标签来声明模块之间的依赖关系        

 添加maven_dao的依赖

com.xxxx
maven_dao
1.0-SNAPSHOT

 在项目中添加UserService类，并添加方法

maven_controller

1. 添加 maven_service 模块的依赖

com.xxxx
maven_service
1.0-SNAPSHOT

2. 添加Servlet的依赖

javax.servlet
javax.servlet-api
3.0.1
provided

3. 新建 Java 类，继承 HttpServlet 类，并重写 service方法

 4. 添加Tomcat插件

5. 启动项目

6. 访问项目

 如图

 

 Maven依赖的基本概念
 依赖的基本配置
根元素project下的dependencies可以包含多个 dependence元素，以声明多个依赖。每个依赖都应该包含以下元素：
1. groupId, artifactId, version : 依赖的基本坐标， 对于任何一个依赖来说，基本坐标是最重要的， Maven根据坐标才能找到需要的依赖。
2. Type： 依赖的类型，大部分情况下不需要声明。 默认值为jar
3. Scope： 依赖范围（compile,test,provided,runtime,system）compile: 编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。test: 测试依赖范围。
使用此依赖范围的Maven依赖，只对于测试classpath有
效，在编译主代码或者运行项目的使用时将无法使用此类依
赖。典型的例子就是JUnit，它只有在编译测试代码及运行测
试的时候才需要。
provided: 已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath
有效，但在运行时无效。典型的例子是servlet-api，编译和
测试项目的时候需要该依赖，但在运行项目的时候，由于容
器已经提供，就不需要Maven重复地引入一遍(如：servlet-
api)。
runtime: 运行时依赖范围。
使用此依赖范围的Maven依赖，对于测试和运行classpath
有效，但在编译主代码时无效。典型的例子是JDBC驱动实
现，项目主代码的编译只需要JDK提供的JDBC接口，只有在
执行测试或者运行项目的时候才需要实现上述接口的具体
JDBC驱动。
system: 系统依赖范围。
该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。
4. Optional：标记依赖是否可选
5. Exclusions： 用来排除传递性依赖。
10.2. 依赖范围首先需要知道，Maven在编译项目主代码的时候需要使用一套classpath。 比如：编译项目代码的时候需要用到spring-core, 该文件以依赖的方式被引入到classpath中。 其次， Maven在执行测试的时候会使用另外一套classpath。 如：junit。最后在实际运行项目时，又会使用一套classpath， spring-core需要在该classpath中，而junit不需要。那么依赖范围就是用来控制依赖与这三种classpath(编译classpath，测试classpath，运行时classpath)的关系， Maven有
以下几种依赖范围：
Compile 编译依赖范围。 如果没有指定，就会默认使用该依赖范围。 使用此依赖范围的Maven依赖， 对于编译，测试，运行都有效。Test： 测试依赖范围。 只在测试的时候需要。比如junitProvided： 已提供依赖范围。 使用此依赖范围的Maven依赖，对于编译和测试有效， 但在运行时无效。 典型的例子是servlet-API, 编译和测试项目的需要， 但在运行项目时， 由于容器已经提供， 就不需要Maven重复地引入一遍。
Runtime： 运行时依赖范围。 使用此依赖范围的Maven依赖，对于测试和运行有效， 但在编译代码时无效。 典型的例子是：jdbc驱动程序， 项目主代码的编译只需要jdk提供的jdbc接口，
只有在执行测试或者运行项目的时候才需要实现上述接口的具体jdbc驱动。
System： 系统依赖范围。 一般不使用。
10.3. 传递性依赖
传递依赖机制， 让我们在使用某个jar的时候就不用去考虑它依赖了什么。也不用担心引入多余的依赖。 Maven会解析各个直接依赖的POM，将那些必要的间接依赖，以传递性依赖的形式引入到当前项目中。
注意： 传递依赖有可能产生冲突！！
冲突场景：
如果A下同时存在两个不同version的C，冲突！！（选取同时适合A、B的版本）

A-->B--->C (2.0)
A-->E--->C (1.0)

A
A
xxx


C
C




B
B