[TOC]
概述
在項目實踐過程中，有個需求需要做一個引擎能執行指定jar包的指定main方法。
起初我們以一個簡單的spring-boot項目進行測試，使用spring-boot-maven-plugin進行打包，使用java -cp demo.jar <package>.<MainClass>執行，結果報錯找不到對應的類。
我分析了spring-boot-maven-plugin打包的結構，又回頭復習了java原生jar命令打包的結果，以及其他Maven打包插件打包的結果，然后寫成這邊文章。
這篇文章里會簡單介紹java原生的打包方式，maven原生的打包方式，使用maven shade插件將項目打成一個大一統的jar包的方式，使用spring-boot-maven-plugin將項目打成一個大一統的jar包的方式，并比較它們的差異，給出使用建議。
Java原生打包
為了簡單起見，假設我們的項目只有一個HelloWorld.java，不使用Maven。假設當前目錄為.，初始目錄下沒有任何內容。
首先，我們在當前目錄新建文件HelloWorld.java。為了演示如何讓編譯的class文件自動放置到與package對應的目錄結構中，特地添加package命令。
package com.hikvision.demo;
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
在當前目錄新建target子目錄，此時，目錄結構如下：
./
├─ HelloWorld.java
├─ target/
編譯
命令：javac HelloWorld.java -d target。目錄結構變為：
./
├─ HelloWorld.java
├─ target/
├─ com/hikvision/demo/
├─ HelloWorld.class
打包
命令：jar cvf demo-algorithm.jar -C target/ .。目錄結構變為：
./
├─ HelloWorld.java
├─ target/
│ └─ com/hikvision/demo/
│ └─ HelloWorld.class
├─ demo-algorithm.jar
打包的結果demo-algorithm.jar，其內部結構為：
demo-algorithm.jar
├─ com
│ └─ hikvision
│ └─ demo
│ └─ HelloWorld.class
└─ META-INF
└─ MANIFEST.MF
其中，MANIFEST.MF的內容為：
Manifest-Version: 1.0
Created-By: 1.8.0_144 (Oracle Corporation)
運行
命令：java -cp demo-algorithm.jar com.hikvision.demo.HelloWorld。
留意上面的jar包的結構，如果我們希望以java -cp的方式運行jar包中的某一個類的main方法，class的package必須對應jar包內部的一級目錄。
這種結構我們稱之為java標準jar包結構。
Maven原生打包
我一般使用mvn clean package命令打包。
maven打包的結果，jar包名稱是根據artifactId和version來生成的，比如對于com.hikvision.algorithm:demo-algorithm:0.0.1-SNAPSHOT的打包結果是：demo-algorithm-0.0.1-SNAPSHOT.jar。
分析這個jar包的結構：
.
├─com
│ └─hikvision
│ └─algorithm
│ └─HelloWorld.class
├─META-INF
│ ├─maven
│ │ └─com.hikvision.algorithm
│ │ └─demo-algorithm
│ │ ├─pom.properties
│ │ └─pom.xml
│ └─MANIFEST.MF
└─application.properties
除META-INF目錄之外，其他的都是class path，這一點符合java標準jar結構。不同的是META-INF有一級子目錄maven，放置項目的maven信息。
對于maven原生的打包結果，可以使用java -cp的方式執行其中某個主類。但是需要注意它并沒有包含所依賴的jar包，這需要另外提供。
使用Maven shade插件打包
Maven打包插件應該不止一種，這里使用的是maven-shade-plugin。
在pom文件中添加插件配置：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
根據上面的配置，在package階段，會自動執行插件的shade目標，這個目標負責將項目的class文件，以及項目依賴的class文件都會統一打到一個jar包里。
我們可以執行mvn clean package來自動觸發shade，或者直接執行mvn shade:shade。
target目錄會生成2個jar包，一個是maven原生的jar包，一個是插件的jar包：
target/
├─ original-demo-algorithm-0.0.1-SNAPSHOT.jar (4KB)
└─ demo-algorithm-0.0.1-SNAPSHOT.jar (6.24MB)
original-demo-algorithm-0.0.1-SNAPSHOT.jar是原生的jar包，不包含任何依賴，只有4KB。demo-algorithm-0.0.1-SNAPSHOT.jar是包含依賴的jar包，有6.24MB。
對照上文可以猜測shade插件對maven原生打包結果進行重命名之后，使用這個名字又打出一個集成了依賴的jar包。
注意，這表示如果執行了mvn install，最終被安裝到本地倉庫的是插件打出的jar包，而不是maven原生的打包結果。可以配置插件，修改打包結果的名稱：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<finalName>demo-algorithm-0.0.1-SNAPSHOT-assembly</finalName>
</configuration>
</execution>
</executions>
</plugin>
使用這個配置，最終的打包結果：
target/
├─ demo-algorithm-0.0.1-SNAPSHOT.jar (4KB)
└─ demo-algorithm-0.0.1-SNAPSHOT-assembly.jar (6.24MB)
此時，demo-algorithm-0.0.1-SNAPSHOT.jar是maven原生的打包結果，demo-algorithm-0.0.1-SNAPSHOT-assembly.jar是插件的打包結果。
插件打包結果的內部結構如下：
├─ch
│ └─qos
│ └─logback
│ ├─classic
│ │ ├─boolex
│ │ ├─db
│ │ │ ├─names
│ │ │ └─script
│ │ ├─encoder
│ │ └─util
│ └─core
│ ├─boolex
│ ├─db
│ │ └─dialect
│ ├─encoder
│ ├─joran
│ │ ├─action
│ │ ├─conditional
│ │ ├─event
│ │ │ └─stax
│ │ ├─node
│ │ ├─spi
│ │ └─util
│ │ └─beans
│ ├─subst
│ └─util
├─com
│ └─hikvision
│ └─algorithm
├─META-INF
│ ├─maven
│ │ ├─ch.qos.logback
│ │ │ ├─logback-classic
│ │ │ └─logback-core
│ │ ├─com.hikvision.algorithm
│ │ │ └─demo-algorithm
│ │ ├─org.slf4j
│ │ │ ├─jcl-over-slf4j
│ │ │ ├─jul-to-slf4j
│ │ │ ├─log4j-over-slf4j
│ │ │ └─slf4j-api
│ │ ├─org.springframework.boot
│ │ │ ├─spring-boot
│ │ │ ├─spring-boot-autoconfigure
│ │ │ ├─spring-boot-starter
│ │ │ └─spring-boot-starter-logging
│ │ └─org.yaml
│ │ └─snakeyaml
│ ├─org
│ │ └─apache
│ │ └─logging
│ │ └─log4j
│ │ └─core
│ │ └─config
│ │ └─plugins
│ └─services
└─org
├─apache
│ ├─commons
│ │ └─logging
│ │ └─impl
│ └─log4j
│ ├─helpers
│ ├─spi
│ └─xml
├─slf4j
│ ├─bridge
│ ├─event
│ ├─helpers
│ ├─impl
│ └─spi
├─springframework
│ ├─boot
│ │ ├─admin
│ │ ├─ansi
│ │ ├─web
│ │ │ ├─client
│ │ │ ├─filter
│ │ │ ├─servlet
│ │ │ └─support
│ │ └─yaml
│ └─validation
│ ├─annotation
│ ├─beanvalidation
│ └─support
└─yaml
└─snakeyaml
├─error
├─tokens
└─util
這里省略了所有的文件，以及大部分的子目錄。
除META-INF目錄外的其他所有目錄，都是classpath，結構和Maven原生的打包結構相同。不同的是shade插件將所有的依賴jar解壓縮之后，和項目的class文件一起重新打成jar包；并且在META-INF/maven下包含了項目本身及所依賴的項目的pom信息。
如果在pom文件中，聲明某個依賴是provided的，它就不會被集成到jar包里。
總的來說，使用maven-shade-plugin打出的jar包的結構依然符合java標準jar包結構，所以我們可以通過java -cp的方式運行jar包中的某一個類的main方法。
使用spring-boot-maven-plugin插件打包
項目首先必須是spring-boot項目，即項目直接或間接繼承了org.springframework.boot:spring-boot-starter-parent。
在pom文件中配置spring-boot-maven-plugin插件：
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
這個插件默認將打包綁定在了maven生命周期的package階段，即執行package命令會自動觸發插件打包。
插件會將Maven原生的打包結果重命名，然后將自己的打包結果使用之前那個名字。比如：
target/
├─ ...
├─ demo-algorithm-0.0.1-SNAPSHOT.jar.original
└─ demo-algorithm-0.0.1-SNAPSHOT.jar
如上，demo-algorithm-0.0.1-SNAPSHOT.jar.original是Maven原生的打包結果，被重命名之后追加了.original后綴。demo-algorithm-0.0.1-SNAPSHOT.jar是插件的打包結果。
這里需要注意，如果運行了mvn install，會將這個大一統的jar包安裝到本地倉庫。這一點可以配置，使用下面的插件配置，可以確保安裝到本地倉庫的是原生的打包結果：
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<!--將原始的包作為install和deploy的對象，而不是包含了依賴的包-->
<attach>false</attach>
</configuration>
</plugin>
spring-boot-maven-plugin打包的結構如下：
.
├─BOOT-INF
│ ├─classes
│ │ └─com
│ │ └─hikvision
│ │ └─algorithm
│ └─lib
├─META-INF
│ └─maven
│ └─com.hikvision.algorithm
│ └─demo-algorithm
└─org
└─springframework
└─boot
└─loader
├─archive
├─data
├─jar
└─util
這里忽略了所有的文件。
分析這個結構，spring-boot插件將項目本身的class放到了目錄BOOT-INF/classes下，將所有依賴的jar放到了BOOT-INF/lib下。在jar包的頂層有一個子目錄org，是spring-boot loader相關的classes。
所以，這個與java標準jar包結構是不同的，和maven原生的打包結構也是不同的。
另外，需要注意的是，即使設置為provided的依賴，依然會被集成到jar包里，這一點與上文的shade插件不同。
分析META-INF/MANIFEST.MF文件內容：
Manifest-Version: 1.0
Implementation-Title: demo-algorithm
Implementation-Version: 0.0.1-SNAPSHOT
Archiver-Version: Plexus Archiver
Built-By: lijinlong9
Implementation-Vendor-Id: com.hikvision.algorithm
Spring-Boot-Version: 1.5.8.RELEASE
Implementation-Vendor: Pivotal Software, Inc.
Main-Class: org.springframework.boot.loader.JarLauncher
Start-Class: com.hikvision.algorithm.HelloWorld
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_144
Implementation-URL: http://projects.spring.io/spring-boot/demo-algorithm/
注意，這里配置了Main-Class，這表示我們可以以java -jar的方式執行這個jar包。Main-Class對應的值為org.springframework.boot.loader.JarLauncher，這表示具體的加載過程是由spring-boot定義的。
這里有一篇文章分析spring boot
jar的啟動過程。我簡單看了下這篇文章，并沒有細讀，我大概猜測到spring-boot實現了一套自己的加載機制，與這個機制相對應的，spring-boot也自定義了一套自己的jar包結構。對我這說，目前了解到這個程度就夠了。
因為不符合Java標準jar包結構，所以無法通過java -cp <package>.<MainClass>的方式運行jar包里的某個類，因為按照標準的jar包結構是找不到這個類的。
從這一點來看，我們需要重新思考什么樣的項目或者module應該做成spring-boot項目？到目前為止，我認為只有完整、可運行的項目或module才需要做成spring-boot項目，比如對外提供rest服務的module。而像common類的module，對外提供公共類庫，其本身無法獨立運行，則不應該作為spring-boot項目。
更何況對于多module的項目，將最頂層的module定義為spring-boot項目，而讓所有的子module都通過繼承頂層module來間接繼承spring-boot-starter-parent的做法，應該是大謬的吧。
總結
- Java原生打包、Maven原生打包、shade插件打包的結果，其結構都是一致的?？梢允褂?code>java -cp的方式執行，一般無法直接使用
java -jar的方式執行。 - 使用spring-boot插件打包，其結構和上述的結構不同。不能使用
java -cp的方式執行，可以使用java -jar的方式執行。 - shade插件會忽略provided的依賴，不集成到jar包里；spring-boot插件會將所有的依賴都集成到jar包里。
- 默認的情況下，shade插件和spring-boot插件的打包結果，會代替Maven原生打包結果被安裝到本地倉庫（執行
mvn install時），可以通過配置改變這一點。
