shade解决mybatis包冲突问题及项目引用的方法

之前写过shade解决mybatis包冲突的文章，主要讲了如何为一个第三方包去打一个shade包，然后它可以解决相同包的不同版本之间的冲突问题；而今天主要说一下在项目里如何引用这个包。
1 如果只是使用包里的资源，而不使用这个包的依赖包，需要这样引用即可

 <dependency>
   <groupId>com.lind</groupId>
   <artifactId>a-start-test-depend-shade</artifactId>
   <version>1.0.4</version>
   <scope>system</scope>
   <systemPath>${project.basedir}/src/main/resources/a-start-test-depend-shade-1.0.4.jar</systemPath>
  </dependency>

2 如果在引用包里，还需要使用它的依赖包，需要把system去掉

<dependency>
   <groupId>com.lind</groupId>
   <artifactId>a-start-test-depend-shade</artifactId>
   <version>1.0.4</version>
   <systemPath>${project.basedir}/src/main/resources/a-start-test-depend-shade-1.0.4.jar</systemPath>
  </dependency>

3 注意：如果你的shade项目和你的当前项目在一起的话，可能能有问题

你可以把shade项目打完jar包之后，移除module，然后再试一下，就可以看到你的jar包里的对象被shade了

4 pom配置文件里的scope是作用域的意思，下面介绍一下几种scope

• compile：默认值 他表示被依赖项目需要参与当前项目的编译，还有后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去
• test：依赖项目仅仅参与测试相关的工作，包括测试代码的编译和执行，不会被打包，例如：junit
• runtime：表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与compile相比，跳过了编译而已。例如JDBC驱动，适用运行和测试阶段
• provided：打包的时候可以不用包进去，别的设施会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是打包阶段做了exclude操作
• system：从参与度来说，和provided相同，不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径

总结