Library Publication 是 Gradle 在0.9.0 时增加的一个新特性,它的作用是让Lib也能发布不同的版本
在这之前,Lib只能发布release版本,你的项目中依赖的所有Lib也都只能是relaese版本的。这种做法看起来很合理,被依赖的库当然应该是release的,debug状态下怎么给其他项目提供依赖呀?但在实际多模块项目中,被依赖的库只是项目中普普通通的一部分,库和项目同时被开发被调试,debug状态的Lib也是非常正常的,于是很早就有人给Google提了一个issue:https://code.google.com/p/android/issues/detail?id=52962 ,Google工程师便在gradle的0.9.0版本中增加了Library Publication特性来处理这个问题,不过好像直到1.0才完全处理好
(转载请注明:博客园-阁刚广志,地址:http://www.cnblogs.com/bellkosmos/p/6437171.html )
对我来说,我写的很多工具包都会打印Log,而工具包自然会放在通用的模块里,所以我当然希望Log能根据模块当前的buildtype来决定是否打印,于是我对这个common lib 使用了Library Publication这个特性
Library Publication 不会改变之前的构建过程,只是在gradle脚本中增加了一些配置,就实现了Lib的多版本发布
Google工程师的实现思路非常简单:
- 还是只需要选择application的variant就可以直接打包
- 改动在于,让 [application依赖的library的variant] 被 [application的variant] 控制
你具体的使用方式是也非常简洁:
- 在library中设置让library发布自己的全部variant:android.publishNonDefault = true
- 然后在application中的reference中标明不同的 [application的variant] 依赖的不同的 [library具体的variant] :debugCompile project(path: ':Library', configuration: 'debug')
但我在实际项目中使用时,发现直接就同步不过去,报错信息是“more than one library with package name:XXX”
正常情况下,Gradle会处理好重复依赖的问题,但是这里居然会报这个错误,那一定是我们在Library Publication时出了问题
原来还是因为我的项目中依赖关系有些乱,造成了一个复杂的构建情况,导致了构建问题,这个问题的原理说起来非常简单:
- 假设有这样一个多模块项目:
- 应用A依赖库B和库C,同时库B和库C又都依赖库D
- 在库D上使用了新特性发布全版本,然后在库C上使用新特性控制:当C是debug的时候D也是debug、C是release的时候D也是release
- 同时在C上也发布全版本,A通过新特性控制C的版本就像C控制D一样
- 而A对B不做控制,B对D也不做控制
- 这时,但是如果你进行debug构建,就会出现问题
- 因为当应用A是debug的时候,库C是被新特性控制成debug的了,同样D也是debug,另一边库B只默认构建release版本,就自然使用了release,而库B依赖的库D因为是普通依赖,自然也是默认的release
- 这样整个项目中就会存在一个debug的库D和一个release的库D,Gradle就报了构建错误:more than one library with package name:XXX
- (如果你对应用A进行release构建,不会有问题,可以自己推理一下原因)
知道原因之后解决这个问题就可以直接对症下药了:让库B也发布全版本,让项目A控制库B的版本,让库B控制库D的版本