DepencyManagement与Dependencies
1.DepencyManagement应用场景
当我们的项目模块很多的时候,我们使用Maven管理项目非常方便,帮助我们管理构建、文档、报告、依赖、scms、发布、分发的方法。可以方便的编译代码、进行依赖管理、管理二进制库等等。
由于我们的模块很多,所以我们又抽象了一层,抽出一个itoo-base-parent来管理子项目的公共的依赖。为了项目的正确运行,必须让所有的子项目使用依赖项的统一版本,必须确保应用的各个项目的依赖项和版本一致,才能保证测试的和发布的是相同的结果。
在我们项目顶层的POM文件中,我们会看到dependencyManagement元素。通过它元素来管理jar包的版本,让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走,直到找到一个拥有dependencyManagement元素的项目,然后它就会使用在这个dependencyManagement元素中指定的版本号。
2、Dependencies
相对于dependencyManagement,所有生命在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。
3、区别
dependencies即使在子项目中不写该依赖项,那么子项目仍然会从父项目中继承该依赖项(全部继承)
dependencyManagement里只是声明依赖,并不实现引入,因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取自父pom;另外如果子项目中指定了版本号,那么会使用子项目中指定的jar版本。
SpringBoot项目打包成jar 不能被依赖
我的 Spring Boot 项目打包成的 jar ,被其他项目依赖之后,总是报找不到类的错误?
spring-boot-maven-plugin
Spring Boot 中默认打包成的 jar 叫做 可执行 jar,这种 jar 不同于普通的 jar,普通的 jar 不可以通过 java-jar xxx.jar
命令执行,普通的 jar
主要是被其他应用依赖, SpringBoot
打成的 jar
可以执行,但是不可以被其他的应用所依赖,即使强制依赖,也无法获取里边的类。但是可执行 jar 并不是 Spring Boot 独有的,Java 工程本身就可以打包成可执行 jar 。
有的小伙伴可能就有疑问了,既然同样是执行 mvnpackage
命令进行项目打包,为什么 Spring Boot 项目就打成了可执行 jar ,而普通项目则打包成了不可执行 jar 呢?
这我们就不得不提 Spring Boot 项目中一个默认的插件配置 spring-boot-maven-plugin
,这个打包插件存在 5 个方面的功能,从插件命令就可以看出:
五个功能分别是:
-
build-info:生成项目的构建信息文件 build-info.properties
-
repackage:这个是默认 goal,在
mvnpackage
执行之后,这个命令再次打包生成可执行的 jar,同时将mvnpackage
生成的 jar 重命名为*.origin
-
run:这个可以用来运行 Spring Boot 应用
-
start:这个在
mvn integration-test
阶段,进行SpringBoot
应用生命周期的管理 -
stop:这个在
mvn integration-test
阶段,进行SpringBoot
应用生命周期的管理
这里功能,默认情况下使用就是 repackage 功能,其他功能要使用,则需要开发者显式配置。
-
首先
mvnpackage
命令 对项目进行打包,打成一个jar
,这个jar
就是一个普通的jar
,可以被其他项目依赖,但是不可以被执行 -
repackage
命令,对第一步 打包成的jar
进行再次打包,将之打成一个 可执行jar
,通过将第一步打成的jar
重命名为*.original
文件
一次打包两个 jar
一般来说,Spring Boot 直接打包成可执行 jar
就可以了,不建议将 Spring Boot 作为普通的 jar
被其他的项目所依赖。如果有这种需求,建议将被依赖的部分,单独抽出来做一个普通的 Maven
项目,然后在 Spring Boot 中引用这个 Maven
项目。
如果非要将 Spring Boot 打包成一个普通 jar
被其他项目依赖,技术上来说,也是可以的,给 spring-boot-maven-plugin
插件添加如下配置:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> </plugins> </build>
配置的 classifier
表示可执行 jar 的名字,配置了这个之后,在插件执行 repackage
命令时,就不会给 mvnpackage
所打成的 jar
重命名了,所以,打包后的 jar 如下:
xxxxxxxxxxxxx.jar(原始的 可被依赖)
xxxxxxxxxxxxx.exec.jar (可执行的)
packaging 的配置
<packaging>pom</packaging>
<packaging>jar</packaging>
<packaging>war</packaging>
在父级项目中的pom.xml文件使用的packaging配置一定为pom。父级的pom文件只作项目的子模块的整合,在maven install时不会生成jar/war压缩包。
Jar包是最为常见的打包方式,当pom文件中没有设置packaging参数时,默认使用jar方式打包。 这种打包方式意味着在maven build时会将这个项目中的所有java文件都进行编译形成.class文件,且按照原来的java文件层级结构放置,最终压缩为一个jar文件。 当我们使用mvn install
命令的时候,能够发现在项目中与src文件夹同级新生成了一个target文件夹,这个文件夹内的classes文件夹即为刚才提到的编译后形成的文件夹。
而在SpringBoot项目中打包成的jar包下会有一个lib目录 里面包含所依赖的jar包和内置tomcat 所以可以直接在jdk下运行
war包与jar包非常相似,同样是编译后的.class文件按层级结构形成文件树后打包形成的压缩包。不同的是,它会将项目中依赖的所有jar包都放在WEB-INF/lib这个文件夹下,如图: WEB-INF/classes文件夹仍然放置我们自己代码的编译后形成的内容。 可想而知,war包非常适合部署时使用,不再需要下载其他的依赖包,能够使用户拿到war包直接使用,因此它经常使用于微服务项目群中的入口项目的pom配置中。
scope属性
compile (编译范围)
compile是默认的范围;如果没有提供一个范围,那该依赖的范围就是编译范围。编译范围依赖在所有的classpath 中可用,同时它们也会被打包。
provided (已提供范围)
provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用。例如, 如果你开发了一个web 应用,你可能在编译 classpath 中需要可用的Servlet API 来编译一个servlet,但是你不会想要在打包好的WAR 中包含这个Servlet API;这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供范围的依赖在编译classpath (不是运行时)可用。它们不是传递性的,也不会被打包。
runtime (运行时范围)
runtime 依赖在运行和测试系统的时候需要,但在编译的时候不需要。比如,你可能在编译的时候只需要JDBC API JAR,而只有在运行的时候才需要JDBC 驱动实现。
test (测试范围)
test范围依赖 在一般的编译和运行时都不需要,它们只有在测试编译和测试运行阶段可用。
system (系统范围)
system范围依赖与provided 类似,但是你必须显式的提供一个对于本地系统中JAR 文件的路径。这么做是为了允许基于本地对象编译,而这些对象是系统类库的一部分。这样的构件应该是一直可用的,Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围,你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的(你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖)。