| 【前言】 |
最近小编接到了一个任务就是将Jboss和maven项目重复的jar包排除一下，要做这件事我们必须要明白为什么Jboss中有的jar包，我们就不需要打包进来，还要有知道maven的各种依赖范围，只要有搞清楚了这些事我们才能更好的完成这项任务。
| 一、Jboss的简单介绍 |
JBoss是企业级应用服务器，小编公司采用的是Jboss-eap-7.1。Jboss是对JavaEE规范实现最好的服务器之一，属于重量级服务器，所谓重量级就是在服务器中已经为我们提供了很多项目所需要的jar包，这样我们在给项目打包的时候就不需要再把这些jar包包含进来，这样我们的程序的体积就会减小运行更快。jboss eap包含一个模块化结构，只允许在需要时启用服务，从而提高启动速度。
所以我们在做项目优化的时候就把这些不需要（Jboss服务器中已经提供的）打包到我们的war包中的jar包排除出去，具体怎么做呢，请看小编接下来的分享。
| 二、maven的依赖介绍 |
maven是一款非常好用的依赖管理软件，我们加载项目的时候只需要一个pom文件就够了，我们先简单介绍一下maven中的依赖管理。
（一）依赖的范围
1）compile：编译依赖范围，这是默认依赖范围，使用此以来范围对于编译、测试、运行三种classpath都有效，典型实例：spring-core。
2）test：测试依赖范围，使用该依赖范围的maven依赖，只对于测试classpath有效，在编译主代码或者是运行项目的时候都无法使用该类依赖，经典实例JUnit。
3）provided：已提供的依赖范围，使用次依赖的maven依赖对于编译和测试的classpath以有效，但在运行时无效，经典实例servlet-api，编译和测试项目的时候需要该依赖，在运行项目时由于容器已经提供就不需要重复引用了。
4）runtime：运行时依赖范围。该毅力啊对于测试和运行classpath有效，但在编译主代码无效，经典实例是JDBC驱动实现，项目主代码只需要JDK提供的JDBC接口，只有在执行测试或运行项目的时候才需要实现上述接口的具体驱动。
5）system：系统依赖范围。该依赖与三种classpath的关系和provided依赖范围完 全一致：但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑 定，可能造成构建的不可移植，因此应该谨慎使用 。
（二）传递依赖的冲突解决
传递依赖：A依赖B，B依赖C（1.1版本），B是A的直接依赖，C就是A的传递依赖，导入D，D依赖C（1.2版本）
1.1 Maven自己调整的原则
1.1.1 第一声明者优先原则
谁先定义的就是用谁的传递依赖
1.1.2 路径近者优先原则
直接依赖级别高于传递依赖
1.2排除依赖
1.3版本锁定：制定项目中依赖的版本
未完待续……
小编排除的过程中遇到了那些坑，使用了什么办法，欢迎关注小编得下一篇博客哟！
| 【总结】 |
只有当理论运用到实践中去，我们才能更好的理解这些知识，才会有更深刻的理解和感受。