当前位置： 首页>编程语言>正文

springboot dependence springbootdependence和parent区别

编程语言2024-05-05 00:32:30


前情提要

maven这个工具用了好久了，但是一直都用的迷迷糊糊的，没有对它进行过系统性的学习，只是知道一些常用的功能怎么实现，所以20190516这一天我从JD购买了徐晓斌老师所著的《maven实战》一书，准备系统性的学习一下maven。

pom结构

我工作的主力语言是java，spring框架这个体系，所以pom文件天天见。

该文件下，有用来声明当前项目坐标的<groupId>,<artifactId>,<name>,<version>这几个字段。还有用来声明依赖的<dependencies>。以及用来声明插件的<build>。

坐标

maven使用由<groupId>,<artifactId>,<version>构成的坐标来唯一确认一个构件（任何类型的maven项目都可被理解为构件）。既然是坐标，那么<groupId>,<artifactId>,<version>的指向就具有唯一性。<version>的命名有有无“-SNAPSHOT”的区别，如果在版本后加了“-SNAPSHOT”，则表示该版本是一个快照版，是不稳定的。快照版有它独特的用处：当你依赖了一个快照版的构件时，maven会在打包时去检查本地仓库中该快照的最新代码（maven默认会每天和远程仓库同步一次数据，这是可以配置的，具体请查阅书籍或者文档），例如，B构件依赖了A构件的“0.1-SNAPSHOT”版本，我给A添加了一些代码，并在仓库重新deploy了一次A的“0.1-SNAPSHOT”。此时你重新构建B，A的“0.1-SNAPSHOT”的新代码就已经被包含进去了。如果没有“-SNAPSHOT”的帮助，B要想使用A的新特性，A需要以新的版本号发布，B需要修改pom去依赖新版本的A，本质上是A提供了新版本坐标，B去依赖新版本。而快照版则是，AB都不修改坐标，但B能使用A的新代码。至于maven是怎么实现的，大家想知道就去看书吧，我就不赘述了，大概就是maven对快照会维护另一个它自己生成的版本号。

依赖

<dependencies>
	<dependency>
		<groupId></groupId>
		<artifactId></artifactId>
		<version></version>
		<scope></scope>、
		<optional></optional>
	</dependency>
</dependencies>

依赖有两个点需要注意，一是依赖的范围，二是依赖的传递性。

依赖范围 <scope>

依赖范围有6：compile,test,provided,runtime,system,import

在介绍这几个范围之前，还需要介绍一个叫做classpath的概念，我个人理解它是编译环境的意思，我没深究。maven有3套classpath，一是编译classpath，二是测试classpath，三是运行时classpath。依赖范围会决定一个构件是否被纳入某个classpath。比如，junit依赖范围选则test，则运行时classpath就不会包含junit包。

编译环境对各个依赖范围的关系是： compile表示进入所有classpath。test表示只进入测试classpath。provided表示进入编译和测试classpath。runtime表示进入运行时和测试classpath。system和provided一致（但system需要多一个<systemPath>参数标签做配合，它是用来引入非maven仓库包的）。inport比较特殊，是用来支撑maven聚合与继承特性的，它和依赖范围没关系，后文再介绍。

默认是compile范围，常见的情况就是给一个test范围，表示只在测试classpath有效，这样在最后的打包文件中，就不会把一些用来测试的包也收录进去，节省空间。

依赖传递性

假如：A依赖B，B依赖C。

从A的角度来说，A对B是第一直接依赖，A对C是传递性依赖，B对C是第二直接依赖。

  • 当第二直接依赖是compile时，传递性依赖的范围和第一直接依赖范围一致。（如C是B的compile依赖，则B是A的什么范围依赖，C就是A的什么范围依赖）。
  • 当第二直接依赖是test时，依赖不会传递。
  • 当第二直接依赖是provided时，只在第一直接依赖为provided时传递，并也是以provided范围传递的。（如c->b=provided,b->a=provided,c->a=provided）
  • 当第二直接依赖是runtime的时候，传递性依赖与第一直接依赖的范围一致，除了compile，它会被传递为runtime。（如c->b=runtime,b->a=compile,c->a=runtime。如c->b=runtime,b->a=test,c->a=test）

最后，有一个叫做<optional>的选项，当它被设置为true时，整个依赖不会被传递。对A来说，看起来就像B没有依赖C一样。此时，A要成功编译，它得自己添加一个C依赖。这个功能是用来解决某些接口有多种实现的场景。到需要的时候大家去查阅书籍吧。此时只要知道有这么个功能就行。

插件

maven归根到底是个编译工具，maven将编译任务拆成了一堆特定的任务，这些任务就组成了maven的生命周期。

三大任务：clean，default，site

  • clean中的子任务
  • pre-clean
  • clean
  • post-clean
  • default中的子任务
  • validate
  • initialize
  • generate-sources
  • process-sources
  • generate-resources
  • process-resources
  • compile
  • process-classes
  • generate-test-sources
  • process-test-sources
  • generate-test-resources
  • process-test-resources
  • test-compile
  • process-test-classes
  • test
  • prepare-package
  • pachage
  • pre-integration-test
  • integration-test
  • post-integration-test
  • verify
  • install
  • deploy
  • site中的子任务
  • pre-site
  • site
  • post-site
  • site-deploy

上面列举的任务是按照maven执行的顺序罗列的。 maven给其中的某几个子任务绑定了默认的执行器，包括clean，compile，test，pachage，install，deloy等，所以拿到maven后你什么都不配置，也能执行mvn clean，mvn install 这样的命令。这些任务的功能我没有记，不过只需要知道大概有这么个体系就行，什么时候需要了，什么时候再去查阅书籍就可以。

看到这些任务，你有没有一种似曾相识的感觉，反正我看到这些任务的时候，顿时就明白，命令行上输入的mvn clean install是什么了，很亲切。实际上，但你在命令行执行mvn指令的时候，就是告诉maven，去执行哪个子任务，而由于任务有先后顺序，所以maven会从第一个任务开始执行，直到你指定的任务为止。而clean，default，site这三个大任务是各自独立的。mvn clean install表示：执行clean任务中的clean子任务，和default任务中的install任务。所以mvn clean install的完整写法其实是：mvn clean:clean default:install。于是maven会从pre-clean执行到clean，以及从validate执行到install。

认识了任务（也就是maven的生命周期），我们就可以认识插件了。maven插件有一个概念叫：goal，也就是目标。这个goal可以理解为是一个方法，用来执行一些逻辑。maven会根据你的配置，把插件的goal绑定到任务上，这个任务在maven中叫做phase！所以还记得你配置插件的时候怎么写的吗？

<build>
	<plugins>
		<plugin>
			<groupId></groupId>
			<artifactId></artifactId>
			<version></version>
			<executions>
				<execution>
					<id></id>
					<phase></phase>
					<goals>
						<goal></goal>
					</goals>
					<configuration></configuration>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

在plugins标签下，申明一个插件，给定插件坐标（groupId,artifactId,version...），设置执行器，将执行器绑定到某个phase（生命周期）上，指定执行什么goal（也就是插件的动作）。如此一来，当maven经过相应任务的时候，就会使用你配置的插件中的goal。

maven不仅支持通过mvn命令行调用生命周期阶段，还支持直接调用插件的goal。我现在最常用的莫非 mvn clean spring-boot:run 。这其中的spring-boot:run,就是

<plugin>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

这个插件提供的功能，这里我们直接调用了spring-boot（spring-boot-maven-plugin的name）插件的run这个goal。

maven自身提供了dependence这个插件，用来查看项目依赖，有兴趣的同学可以去查阅一下，它对于优化项目依赖有很大作用。

maven属性

maven允许你在pom文件中使用"${}"语法来引用属性，那么maven提供了哪些属性，我们如何自己声明属性，就是需要学习的。此处不需要记住，需要时回头来看这部分的总结就可以了。

maven一共提供了6类属性，分别如下：

  • 内置属性
    内置属性主要有常用的两个
  • ${basedir}
    表示项目的根目录，也就是包含pom文件的那个目录
  • ${version}
    表示项目版本
  • POM属性
    这些属性和POM元素对应，其中一些具有默认值，默认值已在超级POM中定义好了。常见的如下。
  • ${project.build.sourceDirectory}
    项目的源码目录：src/main/java/
  • ${project.build.testSourceDirectory}
    项目的测试源码目录：src/test/java/
  • ${project.build.directory}
    项目构建输出目录：target/
  • ${project.outputDirectory}
    项目源码编译输出目录：target/classes/
  • ${project.testOutputDirectory}
    项目测试源码编译输出目录：target/test-classes/
  • ${project.groupId}，${project.artifactId}，${project.version}
    项目坐标
  • ${project.build.finalName}
    项目打包后的文件名，默认：${project.artifactId}-${project.version}
  • 自定义属性
    在POM的<properties>元素下自定义的maven属性，在其他地方用${xxx}形式使用，maven会自动替换。
  • Settings属性
    原理和POM属性相似，只不过Settings属性需要用户使用${settings.xxx}的形式，来引用settings.xml文件中的XML元素属性。常用的有
  • ${settings.localRepository}
    用户本地仓库的地址
  • Java系统属性
    所有java系统属性，maven都可以引用，详细信息可通过mvn help:system指令查看。
  • 环境变量属性
    所有环境变量，maven都可通过${env.xxx}的形式引用。

资源过滤

maven的属性不仅在POM中可以引用，在其他资源文件中也可以引用，只需要设定过滤器就可以。我以spring-boot项目为例，spring-boot项目需要通过<parent>标签设定一个spring boot starter为父工程。如：

<parent>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-parent</artifactId>
	<version>1.5.21.RELEASE</version>
	<relativePath/> <!-- lookup parent from repository -->
</parent>

打开这个父工程的pom你会发现有这样一段配置

<build>
	<resources>
		<resource>
			<directory>${basedir}/src/main/resources</directory>
			<filtering>true</filtering>
			<includes>
				<include>**/application*.yml</include>
				<include>**/application*.yaml</include>
				<include>**/application*.properties</include>
			</includes>
		</resource>
		<resource>
			<directory>${basedir}/src/main/resources</directory>
			<excludes>
				<exclude>**/application*.yml</exclude>
				<exclude>**/application*.yaml</exclude>
				<exclude>**/application*.properties</exclude>
			</excludes>
		</resource>
	</resources>
</build>

原理是，maven使用插件maven-resources-plugin来将项目的资源文件复制到编译输出文件夹下去，通过在<build>标签下申明<resources><resource>标签，你可以改变插件maven-resources-plugin的行为。可以看到，spring boot starter的配置启动了filter去过滤形如**/application*.yml的文件，过滤器会将资源文件中的${xxx}自动替换为pom属性。


https://www.xamrdz.com/lan/5g81941967.html

相关文章：