maven打包命令打出的可执行的jar包和可依赖的jar包的区别

不念不忘少年蓝@ 2024-03-17 09:04 12阅读 0赞

**目录**

引出问题:

介绍打包插件

下面开始打包:

解压比较这两个jar包的区别:

--------------------

####  **引出问题:** ####

当我建了一个maven的springboot项目A写了一个工具类,我把A项目打包成jar包去给B项目用,结果 B项目报错找不到这个jar包.

百度后发现原来jar包分为可执行jar包和可被依赖的jar包

#### 介绍打包插件 ####

下面是我用的springboot的打包插件

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

此插件的package打包命令会打出来两个jar包,

以.jar结尾的就是可执行不可被依赖的jar包

以 `.original后缀的jar包把.original后缀后缀去掉,就能变成可依赖不可被执行的jar包`

![60fa258ec2a8407dabc40406bf8f0255.png][]

细说一下这个打包插件:`s`**`pring-boot-maven-plugin:`**

这个打包插件存在 5 个方面的功能，从插件命令就可以看出：

![3d623902546a46d1ba3f22ce158f8cfd.png][]

五个功能分别是：

*  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 功能，其他功能要使用，则需要开发者显式配置。

**repackage 功能的 作用，分为两步**：

1.第一步:首先 `mvnpackage` 命令 对项目进行打包，打成一个 `jar`，这个 `jar` 就是一个普通的 `jar`，可以被其他项目依赖，但是不可以被执行

`2.第二步:`通过将第一步打成的 `jar`重命名为 `*.original` 文件,得到一个只能被依赖,不能被执行的jar包.

`同时进行repackage` 命令，对第一步 打包成的 `jar` 进行再次打包，将之打成一个 可执行 但是不能被依赖的jar包 .

#### **下面开始打包:** ####

对任意一个 Spring Boot 项目进行打包，可以执行 `mvnpackage` 命令，也可以直接在 `IDEA`中点击 `package.`打包成功之后， `target` 中的文件如下：

![f8c923effeeb406bacc52e79111a0a97.png][]

#### **解压比较这两个jar包的区别:** ####

**可执行 `jar` 解压之后，目录如下：**

![21941e8c611e4c6195f4ef7bc161b35b.png][]

可以看到，可执行 jar 中，我们自己的代码是存在 于 `BOOT-INF/classes/` 目录下，项目中依赖的jar包是放在 `BOOT-INF/lib/` 目录下，还有一个 `META-INF` 的目录，该目录下有一个 `MANIFEST.MF` 文件，打开该文件，内容如下：

![f614e72f738b449696d82b10090725a2.png][]

可以看到，这里定义了一个 `Start-Class`，这就是可执行 `jar` 的入口类， `Spring-Boot-Classes` 表示我们自己代码编译后的位置， `Spring-Boot-Lib` 则表示项目依赖的 `jar` 的位置。

**那么可依赖 jar 的结构呢？**

我们首先给文件重命名,将默认的后缀 `.original` 除去，重命名完成,进行解压：

![24d5009d1cc248ffb3ed2a9744f1d42c.png][]

解压后可以看到，可依赖的 `jar` 根目录就相当于我们的 `classpath`，直接就能看到我们的代码，它是没有把自身用到的jar包打进去的.它也有 `META-INF/MANIFEST.MF` 文件，但是文件中没有定义`jar` 的入口类等。![c12e5f87ac3249e58be41edba489eddd.png][]

**两者不同:**

1.包结构不同,可执行的jar包把我们写的类都放到 `BOOT-INF/classes/` 目录下了,这导致此jar包在作为依赖包时,B项目不能直接访问到com.exampleb包的工具类,这就是此包作为依赖包时报错的根本所在.

而可依赖包则把我们写的类都直接放在了最外面的目录,就是打开jar包的第一级目录上,这样B项目可以直接引用到com.exampleb包的工具类.

2.可执行的jar包把自己项目所依赖的jar包都打包放在了 `BOOT-INF/lib/` 目录下.

而可依赖包并没有把自己项目所依赖的jar包打包,这导致B项目依赖的时候还要自己去下载这些依赖的包.

3. `META-INF/MANIFEST.MF` 文件不同.可执行的jar包中有入口类等配置,而可依赖jar包则缺少这些.

[60fa258ec2a8407dabc40406bf8f0255.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/0c3cb62ab75d43e3896c26b00a9de815.png
[3d623902546a46d1ba3f22ce158f8cfd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/9a016d8057e64ccb8fa34ac15898641a.png
[f8c923effeeb406bacc52e79111a0a97.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/7029b39d150a4772a58e0ec05d2640fc.png
[21941e8c611e4c6195f4ef7bc161b35b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/755c8fa3c0da44e08870a6d620569197.png
[f614e72f738b449696d82b10090725a2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/458991ccc85d44b7bb55c01cfef9d02f.png
[24d5009d1cc248ffb3ed2a9744f1d42c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/2cf811ab56fa4aa48093730498e4babb.png
[c12e5f87ac3249e58be41edba489eddd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/88886fd2b1814b53a4b3be10fb095caf.png