c语言sscanf函数的用法是什么
246
2022-12-16
maven的pom文件与打包详解
目录一、基础配置1、
setting.xml 是全局级别的配置文件,主要用于配置 maven 的运行环境等一系列通用的属性。
pom.xml 是项目级别的配置文件 。 pom 作为项目对象模型。通过 xml 表示 maven 项目,使用 pom.xml 来实现。主要描述了:项目的 maven 坐标、依赖关系、开发者需要遵循的规则、缺陷管理系统、组织和 licenses、项目的 url、项目的依赖性,以及其他所有的项目相关因素。
一、基础配置
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd"> ...
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd">
...
一般来说,上面的几个配置项对任何项目都是必不可少的,定义了项目的基本属性。
1、
< parent> 用于引用父工程,统一管理默认配置以及 jar 包的版本,其依赖需要在子工程中定义才有效。
1)使用 spring-boot-starter-parent
spring-boot-starter-parent 是一个特殊的 starter,它用来提供相关的 Maven 默认依赖:定义 Java 编译版本为 1.8 ;项目使用 UTF-8 编码;继承自 spring-boot-dependencies,这个里边定义了依赖的版本,也正是因为继承了这个依赖,所以我们在写依赖时才不需要写版本号;执行打包操作的配置;自动化的资源过滤;自动化的插件配置;针对 application.properties 和 application.yml 的资源过滤,包括通过 profile 定义的不同环境的配置文件。
2)使用自定义 parent
但是并非所有的公司都需要这个 parent,有的时候,公司会自定义 parent,我们的 SpringBoot 项目只能继承一个 parent,继承了公司内部的 parent 就不能再继承这个了,这个时候怎么办呢?
对于依赖版本,我们可以定义
这样写之后,就可以不用继承spring-boot-starter-parent了,但依赖的版本号问题虽然解决了,但是关于打包的插件、编译的JDK版本、文件的编码格式等等这些配置,在没有parent的时候,这些统统要自己去配置。
Java版本的配置很简单,添加一个plugin即可:
编码格式,在pom.xml中加入如下配置:
2、classifier 元素
这里有必要对一个不太常用的属性 classifier 做一下解释,因为有时候引用某个 jar 包,classifier 不写的话会报错。
classifier 元素用来帮助定义构件输出的一些附属构件。附属构件与主构件对应,比如主构件是 kimi-app-2.0.0.jar,该项目可能还会通过使用一些插件生成,如 kimi-app-2.0.0-javadoc.jar (Java文档)、kimi-app-2.0.0-sources.jar(Java源代码)这样两个附属构件。这时候javadoc、sources 就是这两个附属构件的 classifier,这样附属构件也就拥有了自己唯一的坐标。
3、classifier 的用途:
1)maven download javadoc / sources jar 包的时候,需要借助 classifier 指明要下载那个附属构件
2)引入依赖的时候,有时候仅凭 groupId、artifactId、version 无法唯一的确定某个构件,需要借助 classifier 来进一步明确目标。比如 jsON-lib,有时候会同一个版本会提供多个jar包,在 JDK1.5 环境下是一套,在 JDK1.3 环境下是一套:
引用它的时候就要注明 JDK 版本,否则 maven 不知道你到底需要哪一套jar包:
二、构建配置
Maven 是通过 pom.xml 来执行任务的,其中的
在 Maven的pom.xml 文件中,存在如下两种
全局配置(project build):是
局部配置(profile build):是
字段说明
1、finalName:build目标文件的名称,默认情况为 ${artifactId}-${version}。
2、defaultGoal:执行 build 任务时,如果没有指定目标,将使用的默认值。如上配置,在命令行中执行 mvn,则相当于执行 mvn install。
3、directory:build 结果文件的存放目录,默认在 ${basedir}/target 目录。
4、filter:定义 *.properties 文件,包含一个 properties 列表,该列表会应用到支持 filter 的 resources 中。也就是说,定义在 filter 的文件中的 name=value 键值对,会在 build 时代替 ${name}
值应用到 resources 中。maven 的默认 filter 文件夹为 ${basedir}/src/main/filters。
5、resources: 一个 resource 元素的列表。每一个都描述与项目关联的文件是什么和在哪里。
6、testResources: 定义和resource类似,只不过在test时使用。
7、Project Build 特有的 <…Directory>:往往配置在父项目中,供所有父子项目使用。
8、Project Build 特有的
9、plugins:
groupId
artifactId
version
extensions:是否加载该插件的扩展,默认false;
inherited:该插件的 configuration 中的配置是否可以被(继承该POM的其他Maven项目)继承,默认true;
configuration:该插件所需要的特殊配置,在父子项目之间可以覆盖或合并;
dependencies:该插件所特有的依赖类库;
executions:该插件的某个goal(一个插件中可能包含多个goal)的执行方式。一个execution有如下设置:
id:唯一标识;
goals:要执行的插件的goal(可以有多个),如
phase:插件的goal要嵌入到Maven的phase中执行,如verify;
inherited:该execution是否可被子项目继承;
configuration:该execution的其他配置参数;
10、
三、profile 配置
有些时候,一个项目需要适配多种开发环境,如数据库不同(mysql、oracle、db2等)、如开发环境不同(dev、pro、test)等不同的环境需要指定不同的配置。这种情况下,我们就可以采用配置 profiles 来控制。在启动的时候指定不同的配置组合,maven进行build时会自动选择指定配置。
四、springboot 打包配置
SpringBoot 自带Tomcat,所以我们的项目可以单独部署,不需要依赖 Window、Linux 系统中的服务器,所以打包出来的 Jar 包是可以直接运行的。
打包插件
SpringBoot 项目可以通过 maven 的插件进行打包,分为两种情况:
(1)项目以 spring-boot-starter-parent 作为 parent
(2)项目不以 spring-boot-starter-parent 作为 parent
有时项目的 parent 不是 spring-boot-starter-parent,而是自定义的配置,此时 spring-boot-maven-plugin 插件不能直接使用,需要做一些修改。
经过这样配置,就可以进行打包了。
1、Maven 项目结构
Maven 项目的标准目录结构:
构建 Maven 项目的时候,如果没有进行特殊的配置,Maven 会按照标准的目录结构查找和处理各种类型文件。
(1) src/main/java 和 src/test/java 这两个目录中的所有 *.java 文件会分别在 compile 和 test-comiple 阶段被编译,编译结果分别放到了 target/classes 和 targe/test-classes 目录中,但是这两个目录中的其他文件都会被忽略掉。
(2) src/main/resouces 和 src/test/resources 这两个目录中的文件也会分别被复制到 target/classes 和target/test-classes 目录中。
在 springboot 项目中,打包插件默认会把这个目录中的所有内容打入到 jar 包或者 war 包中,然后放在 BOOT-INF 目录下。
2、打包时资源文件的配置
(1)打包 src/main/java 目录下的 xml
一般情况下,我们用到的资源文件(各种xml,properites,xsd文件等)都放在src/main/resources下面,利用 maven 打包时,maven 能把这些资源文件打包到相应的 jar 或者 war 里。
有时候,比如 mybatis 的 mapper.xml 文件,我们习惯把它和 Mapper.java 放一起,都在 src/main/java 下面,这样利用 maven 打包时,就需要修改 pom.xml 文件,来把 mapper.xml 文件一起打包进 jar 或者 war 里了,否则,这些文件不会被打包的。(maven认为src/main/java只是java的源代码路径)
例如:
默认情况下,执行 mvn clean package 打包命令后在 target\classes 目录下不会把 UserMapper.xml 打包到下 mapper 目录下。
解决方法有如下几种:
1)配置 POM.XML 的 resource 把 xml 也打包到 mapper 目录下
2)maven-resources-plugin 插件
为了使项目结构更为清晰,Maven区别对待Java代码文件和资源文件,maven-compiler-plugin用来编译Java代码,maven-resources-plugin则用来处理资源文件。
默认的主资源文件目录是src/main/resources,很多用户会需要添加额外的资源文件目录,这个时候就可以通过配置maven-resources-plugin来实现。
3)build-helper-maven-plugin 插件
(2)src/main/resources 目录下的 xml 等资源文件不被打包
默认 resources 目录下的文件都会被打包,如果想 resources 目录下的 xml 文件不被打包,可通过如下配置:
当然也可以通过插件来实现:
实现的效果如下:
编译好之后,会在target目录下生成 conf 目录并且把 resources 目录下的所有文件都自动拷贝到 target/conf/ 目录下。
四、仓库配置
五、发布配置
六、pom 项目依赖、继承与聚合
1、项目之间的相互依赖
现在有两个项目,HelloWorld1 和 HelloWorld2,如果 HelloWorld1 要引用 HelloWorld2 中的方法,也就是 HelloWorld1 要依赖 HelloWorld2。做法如下:
(1)在 helloworld1 项目之中,执行打包命令将当前项目打包成可依赖的 jar 包,并放进本地仓库当中;
(2)在helloworld2 项目的 pom.xml 之中,加入 helloworld1 依赖。helloworld 的 jar 包坐标:
(3)通过 import 导入 jar 包,就成功的引入我们自定义的项目 jar 包。这样就可以使用
helloworld1 项目的所有方法。
如何打包成可依赖的 jar 包
在 SpringBoot 工程中使用 spring-boot-maven-plugin 的默认配置 build,那么所生成的 jar 包虽然是可执行的,但却是不可被依赖的。
通过修改 pom.xml 中 spring-boot-maven-plugin 的配置,可以让所在工程一次打包生成两个 jar 包,其中 XXX.jar 可作为其它工程的依赖,XXX-exec.jar 可被执行。
classifier 指定了可执行 jar 包的名字,默认的 jar 包则作为可被其他程序依赖的 Artifact。配置完成后对项目进行打包,会生成以下两个 jar 包。
SpringbootDemo-1.0-SNAPSHOT.jar 是一个可以被其他项目依赖的 jar,
SpringbootDemo-1.0-SNAPSHOT-exec.jar 是一个可执行的 jar。
对其分别解压,可以看到 class 路径是不同的:
2、maven 父子项目依赖的继承
现在有两个项目 A 和 B,继承就是说 B 项目之中依赖的包 A 项目也可以使用。一般用于统一管理依赖版本号等
具体实现如下:
(1)创建父工程 parent,打包方式为 pom,并在其中依赖 junit.jar,注意要将依赖写在
Maven 提供了
在
如下:
(2)在子工程 Helloworld 的 pom.xml 当中添加父工程标签,这里的
(3)在子工程当中,声明需要使用父类当中的哪些 jar 包,声明写在 pom.xml 的
可以看到有一个向上继承的符号,说明继承已经成功了。更新之后发现 junit 已经导入。
3、多模块项目的聚合
如果一个项目有多个模块,也叫做多重模块,或者合成项目。
如果不用聚合那么每次打包每个模块都要运行,但是用来聚合后,只运行一次就行了。
如果多个模块有相同的内容,那么就可以用一个父模块来实现相同的内容,其他模块只要继承父模块就行了。
父模块中把所有 jar 包都引用进来,子模块就不用配置 jar 包的版本和作用域了。(继承)
反应堆:
在一个多模块的 Maven 项目中,反应堆是指所有模块组成的一个构建结构。反应堆包含了各个模块之间的继承与依赖关系,从而能够自动计算出合理的模块构建顺序。
实际的构建顺序为: ~parent, ~email, ~persist。可见构建的顺序并不是声明的顺序。
该例中 account-email 和 account-persist 都依赖于 account-parent,那么 account-parent 就必须在另外两个模块之前构建。
实际的构建顺序是这样的:Maven 按声明顺序读取 POM,如果 POM 没有依赖模块,那么就构建该模块,否则就先构建其依赖的模块;如果依赖的模块还依赖于其他模块,则进一步构建依赖的依赖。
模块之间的关系将反应堆构成一个有向非循环图,各个模块是该图的节点,依赖关系构成又向边,这个图不允许出现循环,因此当出现 A 依赖于 B,B 又依赖于 A 的情况时 Maven 就会报错。
4、聚合与继承的关系
(1)区别 :
1)对于聚合模块来说,它知道有哪些被聚合的模块,但那些被聚合的模块不知道这个聚合模块的存在。
2)对于继承关系的父 POM 来说,它不知道有哪些子模块继承与它,但那些子模块都必须知道自己的父 POM是什么。
(2)共同点 :
1)聚合 POM 与继承关系中的父 POM 的 packaging 都是 pom;
2)聚合模块与继承关系中的父模块除了 POM 之外都没有实际的内容。
现有的实际项目往往是一个POM既是聚合POM又是父POM,这么做主要是为了方便。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~