Java的常用的依赖方式通常有三种，即Maven，jar（aar）包，和源码依赖，不同的依赖方式可以组合使用，但他们组合使用时候坑确实很多，下面我们就讨论集中比较常见的情况，这也是我们开发者在进行多模块开发时候会遇到的问题。

在进行多模块开发过程中，我们通常把经常需要变动的业务模块使用源码依赖的方式进行依赖，如下所示：

api project(":mavenlibrary2")
implementation project(":mavenlibrary2")

而公共库以及很少变动的模块，通常使用Maven方式进行依赖，如下所示：

implementation 'io.lecon.app:depdemo:1.0.0'

想法是非常好的，但是实际开发过程中，随着代码量的增大就显得不是那么回事儿了。业务模块还好说，都是源码依赖方式，基本上不会出现什么问题。但是在使用Maven进行依赖的公共库模块就发生了问题。下面看一种情况：

业务模块正常依赖这个不用管，但是公共模块中同样很多模块进行开发。这时候我们业务模块使用Maven的方式对公共模块进行依赖，那么公共模块的各个子模块之间的依赖方式是什么呢？Maven，源码？这样说你可能不好理解，如下图所示:

2019年04月12日-1.png

先说答案，只能使用Maven的方式依赖
Maven在进行打包的时候，不会将源码依赖的子功能打包进去，但是会保存依赖信息。如果你确实这么做了的话，也许会遇到这样的错误：

ERROR: Failed to resolve: AppLibrary:mavenlibrary2:unspecified

在进行公共模块开发时候，可以使用源码的方式进行依赖，但是最后放到业务里面运行的时候，公共模块的所有子模块之间一定要全部使用Maven方式进行依赖。

但是这样就会出现一个问题，不同的模块版本号之间如何保持一致？
其实这是一个很严重的问题，不同版本之间开放的api很有可能不一样，而这些问题在编译时候不一定会报出来，也就是说在运行时会发生类找不到的问题。所以在要把所有Maven依赖的项目的版本号以及依赖顺序要统一管理起来，这个话题下次再说。