maven版本依赖提供了方便的同时，有时候也会冒出一些诡异的问题。此次遇到的问题，比较简单，旨在记录，欢迎拍砖。
一、问题背景
由于使用了jekenis进行代码部署，所以maven的编译打包都会在这上面完成。在描述具体问题之前，我想先说一下打包的规则：项目A对外提供服务，A发布的包就会对外提供两个包（一个是api包即暴露的接口，一个是client包，封装了对api包的调用，将API包里面需要配置的服务端接口信息揉在一起。这样做的好处就是对客户端屏蔽zk上具体的接口信息）现在的问题是B项目依赖于A项目的client包，client包版本比较低，所以需要做升级。
二、问题描述
A项目中增加了methodA()方法，B项目需要升级client包，由于历史原因，api包的版本和client包版本不一致，此次升级顺便统一版本。当开心的提交完代码和单元测试，就等着jekenis构建了，结果跑单元测试的时候，发现如下问题：
看到如此画面，相信看异常堆栈已经能发现问题，缺少方法呗，但是明明写了呀，而且本地跑单元测试没问题。然后觉得可能是导包导的不对，但是看pom文件只依赖于client包，client包已经升级了，为什么还有问题
三、定位问题
带着疑问我怀疑是jekenis的问题（当然中间有很多弯路，加调试信息），我打开了jekenis的包依赖页面（没注意过？选择构建的项目，点进去后，有个See Fingerprints ，然后打开就是了）我搜索那个client包，发现旁边的api包版本仍然比较低，什么鬼，低版本的api包里肯定没有那个方法，然后点详细信息链接到A项目中去了，然后回到A项目查看依赖，改成新版本号后（下面的snapshot不规范，已修正），然并卵，怀疑是jekenis查找仓库仍然找的是老包，于是乎就想去jekenis对应的maven库里把相关的包都rm -rf 了，悲剧的是我还没有那台机器权限
。。。。。
四、解决方案
既然已经猜到是包不对了，下面就是删包了，回想一下，jekenis是从私服上拉包，那在私服上直接干掉这个版本不就更新了，最后就这样给搞定了。不过还有其他一系列环境问题，不在此次讨论范围内，先不描述了