背景
我们迁移了一批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>
