首页>>后端>>java->maven项目打包全面解析

maven项目打包全面解析

时间:2023-12-07 本站 点击:0

1 前言

由于要对敏感数据加密,之前做了一个加密工具 要整个平台使用,所以将加密代码项目打成了jar包。很简单,但是也遇到了一些问题,下面分享将项目打包及打包中遇到的问题和经验

2 实现

1) 项目打包

idea项目打包很简单,只需要执行 mvn clean  mvn install就可以了,也可以手动执行

执行后查看下打包后文件

打包成功!

2)项目依赖问题

打包成功只是开始,其实jar包还要注意一些问题,因为jar包是要被很多项目所引入的,jar包项目中本身也会引入一些依赖,如果不注意,就会导致项目中依赖混乱,最后很可能到只依赖冲突,在实际的开发中,大部分开发都会遇到依赖冲突的情况,而且比较难定位,这个和maven的依赖管理息息相关,所以在我们打jar包时就要考虑到,一定要做好maven依赖的管理。

<dependencies>    <dependency>        <groupId>org.slf4j</groupId>        <artifactId>slf4j-api</artifactId>        <version>1.7.25</version>        <scope>provided</scope>    </dependency></dependencies>

我的项目很简单,只引入了slf4j-api,而我对他的作用于描述是provided,provided的作用是,当其他项目引入我的jar包时,slf4j-api不会传递给其他项目,因为他是私有的,这样就是防止了依赖的乱用。

但是思考了一下,这里是存在问题的,provided之所以不会传递给其他引入jar包的项目是因为打包时没有将他修饰的依赖打包进去,这样一定要要求,引入这个依赖的项目本身就有这个provided修饰的依赖,比如servlet api,因为tomcat本身有这个提供这个依赖,所以可以声明为provided。

provided属于maven修饰作用域中的其中一个,我们看看maven作用域的介绍

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 仓库中引用赖)。

回到我的打包jar项目,最终我进行的依赖时

<dependencies>    <dependency>        <groupId>org.slf4j</groupId>        <artifactId>slf4j-api</artifactId>        <version>1.7.25</version>    </dependency></dependencies>

这样可能会造成依赖传递,不过maven提供了另外一种方式,防止依赖的滥用

         <groupId>groupId</groupId>          <artifactId>artifactId</artifactId>          <version>version</version>         <exclusions>              <exclusion>                  <groupId>*</groupId>                  <artifactId>*</artifactId>              </exclusion>         </exclusions>      </dependency>

这种形式就可以排除掉所引用依赖中所引用的其他依赖,也就防止了依赖冲突发生的可能性,对于我这次的依赖而言,是一个日志依赖,比较简单,所以没有使用这种形式,但是对于一些较多依赖的项目,使用这种形式我认为还是不错的

3) 配置文件读取问题

功能需要首先读取配置文件,使用静态代码块赋值静态属性,在本地测试的时候读取文件是没有问题的,将项目打包成jar包后,却发现可以读取到配置文件,但是配置文件里面却读取不到内容

static {    AESConfig.readConfigFile();}

public static void readConfigFile() {    ResourceBundle resourceBundle = ResourceBundle.getBundle(AES_UTILS);    key = resourceBundle.getString(DST_AES_KEY);

经过排查发现是因为打包之后,代码读取的配置文件读取成了同名的引入改jar包项目的配置文件,导致读取不到配置,存在一个规则,项目会有限读取项目本身的资源文件再读取jar中的配置文件

查看了一下读取配置文件的源码,ClassLoader中的getResource方法,类似于loadClass进行双亲委派,也是先找父类加载器,只不过这个算资源文件加载器吧,双亲委派防止子类覆盖父类,这个对资源的加载处理估计也是处理覆盖问题

public URL getResource(String name) {    URL url;    if (parent != null) {        url = parent.getResource(name);    } else {        url = getBootstrapResource(name);    }    if (url == null) {        url = findResource(name);    }    return url;}

设定maven项目版本号,打包项目发布到远程场库,这样一个jar包项目就完成了。

3 结语

有时候很简单的东西里面也蕴含了很多的小问题,而这些小技术都是非常基础的技术能力,比如maven的作用域,maven的依赖管理,这些都是非常微小的且在我们日常开发中经常能过看到的,资源文件的读取也是很简单的,但是是如何读的却是很复杂的,关注每一个微小的技术,也是一个不小的进步吧

原文:https://juejin.cn/post/7106392257653276702


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/java/18670.html