一个maven工程改了包名都需要改哪些配置_Maven工程的关系

Maven的声明周期：

在依赖的链条上，被依赖的工程如果依赖其他工程，那么链条中上面的工程就不必重复声明依赖了，Maven会自动导入。

（2）依赖传递的限制性 
compile范围的引入可以传递
test、provide范围的引入不可传递

对于不可传递的依赖只能在有需要的工程模块中单独引入

（3）依赖传递性的排除
（4）声明属性值
（5）依赖的原则

生命周期&&插件

（1）maven中有三个独立的生命周期

[1]Clean：清理
[2]Site：生成站点
[3]Default：默认

（2）每个生命周期都有这个特点：

不管用户要求执行的命令对应生命周期中的哪一个阶段，Maven都会自动从当前生命周期的最初位置开始执行，直到完成用户下达的指令

一个完整的项目构建过程通常包括清理、编译、测试、打包、集成测试、验证、部署等步骤，Maven从中抽取了一套完善的、易扩展的生命周期。Maven的生命周期是抽象的，其中的具体任务都交由插件来完成。Maven为大多数构建任务编写并绑定了默认的插件，如针对编译的插件：maven-compiler-plugin。用户也可自行配置或编写插件。

4.1 . 三套生命周期

clean、default、site，每个生命周期都包含了一些阶段（phase）。三套生命周期相互独立，但各个生命周期中的phase却是有顺序的，且后面的phase依赖于前面的phase。执行某个phase时，其前面的phase会依顺序执行，但不会触发另外两套生命周期中的任何phase。

4.1.1clean生命周期

1. pre-clean ：执行清理前的工作；
2. clean ：清理上一次构建生成的所有文件；
3. post-clean ：执行清理后的工作

4.1.2default生命周期

default生命周期是最核心的，它包含了构建项目时真正需要执行的所有步骤。

• 声明周期指令

1. validate
2. initialize
3. generate-sources
4. process-sources
5. generate-resources
6. process-resources ：复制和处理资源文件到target目录，准备打包；
7. compile ：编译项目的源代码；
8. process-classes
9. generate-test-sources
10. process-test-sources
11. generate-test-resources
12. process-test-resources
13. test-compile ：编译测试源代码；
14. process-test-classes
15. test ：运行测试代码；
16. prepare-package
17. package ：打包成jar或者war或者其他格式的分发包；
18. pre-integration-test
19. integration-test
20. post-integration-test
21. verify
22. install ：将打好的包安装到本地仓库，供其他项目使用；
23. deploy ：将打好的包安装到远程仓库，供其他项目使用；

---

Maven工程的关系

3.1依赖

• • • • 即 A 工程开发或运行过程中需要 B 工程提供支持，则代表 A 工程依赖 B 工程。在这种情况下，需要在 pom.xml 文件中增加下属配置定义依赖关系
• 依赖的体系使用的标签是
• dependencies（依赖性）
  • • 使用子标签dependency（进行对一个构件的映射）：
    • 存放的位置是在配置得本机的仓库repo内
    • 使用dependency标签配置一个依赖和构件的导入一样的

<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.12</version>
			<scope>test</scope>
		</dependency>
	</dependencies>

• 引入其他项目的和其他的项目产生依赖关系
• 在项目的pom文件内保存的当前项目的gav坐标
• 引入的后在MeavnDependencies内加如项目的文件

• 引入：

 <dependencies>
  	<dependency>
  		<groupId>com.sxt</groupId>
		<artifactId>DemoMeavn1</artifactId>
		<version>0.0.1-SNAPSHOT</version>
  	</dependency>
  </dependencies>

• 项目之前的依赖会将依赖的项目的所有导入到当前的项目
• 依赖的需要对项目进行打包
• 如果项目有更新需要重新清除原先的打包，重新打包
• 依赖工程有效范围使用scope标签进行配置
• csope标签的作用是进行设置当钱前工程的有效范围
  • • 1.compile：编译中有效
    • 2.runtime：运行中有效
    • 3.system：全部中有效（默认）
    • 4.provided：当前工程中有效
    • 5.test：只在测试中有效

---

3.2继承关系

• 如果 A 工程继承 B 工程，则代表 A 工程默认依赖 B 工程依赖的所有资源，且可以应用 B 工程中定义的所有资源信息。被继承的工程（B 工程）只能是 POM 工程。
• 资源引入的步骤

• 继承父项目后，子项目内的pom.xml内多了一个parent标签

• 在pom工程内使用dependencyManagement标签进行构件的导入
• properties标签的作用：
  • • 1.properties标签可以写入任何的标签，一般使用在构件的版本方便的控制
    • 2.在子项目内可以不写构件的版本字只需要引入groupid和artifactid即可
    • 3.使用properties：标签进行集中的版本控制

 <properties>
  <!-- 标签名字可以自定义 -->
  	<test-version>4.12</test-version>
  </properties>

 <!-- 
  		1.properties标签可以写入任何的标签，一般使用在构件的版本方便的控制
  		2.如下将构件的标签单独的提取出来方便设置版本控制
   -->
  <properties>
  	<test-version>4.12</test-version>
  </properties>
  <!-- 
  		1.在pom工程内是用dependencyManagement标签设置构件的导入
   -->
  <dependencyManagement>
  		<dependencies>
  			<dependency>
  				<groupId>junit</groupId>
				<artifactId>junit</artifactId>
				<!-- 使用${}符号引用设置在properties内设置的自定义的标签 -->
				<version>${test-version}</version>
  			</dependency>
  		</dependencies>
  </dependencyManagement>

• 子项目的引用：
  • • 1.需要引用groupid（项目包名）和artifactid（工程名）

<dependencies>
  	<dependency>
  	<!-- 直接引用父项目的构件即可
  			1.引用groupId
  			2.引用artifactId		
  	 -->
  		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
  	</dependency>
  </dependencies>

---

3.3聚合

当我们开发的工程拥有 2 个以上模块的时候，每个模块都是一个独立的功能集合。比如

某大学系统中拥有搜索平台，学习平台，考试平台等。开发的时候每个平台都可以独立编译，

测试，运行。这个时候我们就需要一个聚合工程。

在创建聚合工程的过程中，总的工程必须是一个 POM 工程（Maven Project），各子模

块可以是任意类型模块（Maven Module）。所有聚合工程和聚合模块必须处于同一个组

（groupId）中，且聚合工程可以嵌套。

• 聚合工程的要求
  • • 1.要求子modul的Groupid和根项目的Groupid保持一致
    • 2.要求根项目必须是一个pom项目

注意：

• 继承和项目都是确定的好
• Groupid要和根项目的GroupId保持一致

• 根项目内每创建一个子项目都会在modules标签内添加一个子标签module值为子项目的工程名称artifactid的值

创建web工程的方式

• • • 注意
    • maven工程默认下是没有WEB-INF这个的文件夹的，也没有web.xml，为了工程的完整性需要自己添加
    • 并且web.xml需要加如web工程的约束头文件