背景
我们迁移了一批shared Libraries (作为dependecny供其他项目使用),在这个过程中为了让这些迁移后的shared Libraries build通过,我们需要基于原本的pom添加了一些新依赖。
问题描述
我们发现对于依赖了迁移后的shared Libraries的几个项目在启动的时候都出现了同样的异常
Exception in thread "main" java.lang.NoSuchMethodError:xxxxxxxxxxxx
分析
通过定位,我们发现是项目P调用了一个实例方法,但是该类里面却没有定义这个方法。我们很容易想到是因为现在依赖的jar冲突覆盖了以前正确的jar。通过Dependency分析,我们发现是我们jar X里面新加进来的dukes-api:1.3.6覆盖了另外一个jar Y带进来的的dukes-api:1.5.1。而这个调用的方法只在1.5.1里面才有。 如图所示:
这里你可能会说,那X里面的pom直接定义dukes-api:1.5.1不就解决了问题。但真实情况是dukes-api:1.5.1并不能使X本身build通过。那么有什么办法可以让项目X本身build通过生成对应的jar并且保证项目P依赖的dukes-api:1.5.1不会被覆盖呢。这里我们可以通过调整maven的scope来控制。
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
官方文档详细记载了maven有6种scope
1.compile
默认scope,会随着项目一起打包,依赖会传递到上层项目,编译、测试、运行都有效
2.test
仅参与测试过程,只在编译测试代码和运行测试代码的时候被使用
3.provided
在编译和测试的时候需要,不会随着项目一起打包,所以不会传递到上次项目。正因为运行时无效,典型的应用场景的可以避免当前项目的servlet api和tomcat容器提供的servlet api冲突。
4.runtime
在运行和测试时候需要,不参与项目编译。比如项目只需要驱动接口参与编译,只有运行项目时才会需要该接口的具体实现。
5.system
这个和provided类似,不同点在于需要显式指定一个本地文件系统的jar路径
<dependency>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
<version>1.6.1</version>
<scope>system</scope>
<systemPath>${basedir}/Webcontent/WEB-INF/lib/jaxen.jar</systemPath>
</dependency>
6.import
这个scope仅仅适用于dependencyManagement。这个可以实现maven的多继承,dependency的version可以被当前项目的parent pom管理起来,但是如果你希望另外一批(不在当前parent pom里面)jar的version也可以被单独管理,你可以自定义一个pom,然后在dependencyManagement里面import进来
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.xxxxx</groupId>
<artifactId>xxxx</artifactId>
<version>xxxxxxxxxx</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
解决方案
我们最后的solution是将X里面添加的依赖dukes-api:1.3.6的scope定义为provided。这样dukes-api:1.3.6只参与项目X的编译,最终不会被项目P使用从而覆盖dukes-api:1.5.1.
<dependency>
<groupId>com.xxxxx</groupId>
<artifactId>dukes-api</artifactId>
<version>1.3.6</version>
<scope>provided</scope>
</dependency>