maven项目打包全面解析

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第2天，点击查看活动详情

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的依赖管理，这些都是非常微小的且在我们日常开发中经常能过看到的，资源文件的读取也是很简单的，但是是如何读的却是很复杂的，关注每一个微小的技术，也是一个不小的进步吧