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的属性来定义路径

总结

到此这篇关于shade解决mybatis包冲突问题及项目引用的方法的文章就介绍到这了,更多相关shade解决mybatis包冲突内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！