有时候在项目开发中，需要很多依赖的 jar 包，其中依赖的 jar 包也会依赖其他的 jar 包，导致jar 包的管理很容易不全，以下有两种方法可以规避这个问题。（https://blog.csdn.net/mrzhangbaby/article/details/88356178）
一、在pom.xml 文件中配置，将依赖的 jar 包放到指定的文件夹中
在 pom.xml 的 build-plugins 节点上添加以下配置即可
<!-- 将项目的依赖包复制到 target/lib -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
二、将项目打jar 包时，将依赖的 jar 包一起并入到项目 jar 包中
在 pom.xml 的 build-plugins 节点上添加以下配置即可
<!-- 配置将依赖包一并打入到项目的 jar 包中 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<archive>
<manifest>
<mainClass></mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- 指定在打包节点执行jar包合并操作 -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
三、打包牵扯到的依赖问题，做开发久了就会有一个jar包冲突的问题-->详细解释如下，几种模式：
Dependency Scope
在POM 4中，<dependency>中还引入了<scope>，它主要管理依赖的部署。目前<scope>可以使用5个值：
* compile，缺省值，适用于所有阶段，会随着项目一起发布。
* provided，类似compile，期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
* runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
* test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
* system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。
依赖范围控制哪些依赖在哪些classpath中可用，哪些依赖包含在一个应用中。让我们详细看一下每一种范围：
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仓库中引用依赖）。
对于maven的使用，只能说是无可奈何，不用jar包不好找。用了有的jar包下不了。
可能我没有刻意的研究过吧，有时候下载网速了，阿里云远程地址jar包缺失了，呵呵呵。。。。
生产环境打包测试命令
1) 项目打包方式
如果在eclipse 中，则需要如下 maven 参数进行打包：
-P local clean package：不打包第三方依赖 -P dev clean package install：打包第三方依赖