工作中内部用到的一些通用的功能库例如util库，网络库，控件库等，被 单独抽取出来生成jar或者aar，放到公司内部的maven服务器上，其他工程通过maven引用到这些通用库。通用库一般都是功能比较稳定，不会频繁迭代，但是还是会碰到有需要修改的时候，修改完后发布到maven上，一般正式发布是需要版本号+1。
今天碰到的一个问题，背景：app工程XXXProject，有个CommonModule的module，这个commonModule引用了libA和libB，同时libB又引用了libA。libA和libB是作为通用框架库部署在内部maven服务器上。libA和libB有过修改，后面又以同样的版本号被发布到maven服务器上。在gradle项目工程里sync工程，则会先去本地的.gradle目录（默认是C:\Users{用户名}.gradle\caches\modules-2）里去找，如果找到，就直接用本地的，否则才去远程sync下来。所以，如果同版本号的库要重新sync下来，需要去.gradle目录里把对应包名里的文件删掉。jar或者aar在：C:\Users{用户名}.gradle\caches\modules-2\files-2.1里。今天碰到的问题删了前面提到的路径下的文件后，sync的时候还是碰到以下错误：
Error:A problem occurred configuring project ':XXXXProject'.
Could not resolve all dependencies for configuration ':XXXProject:_DebugPublishCopy'.
Could not find CommonLibs:libA:unspecified.
Required by:
project : CmmonModule> libB:1.0.0
通用库的包上传到maven上，maven是会存储这个aar或者jar文件，同时也会维持一份配置，标明该aar/jar依赖哪些其他的库。这个依赖配置信息是会同时sync下来到gradle的本地仓库里（默认路径C:\Users{用户名}.gradle\caches\modules-2\metadata-2.16\descriptors
上面的异常，是由于libA和libB重新修改时候编译里一些配置有改变，导致maven配置文件有修改。所以这里操作要注意的要点：
- 如果lib库同版本更新，重新sync工程，需要同时删除 modules-2\files-2.1和metadata里这2个lib对应的目录，然后重新sync一下就可以了。
- lib库正式发布应该版本号+1
