简短形式:组织AAR的代码/ POM有哪些方法,使用该AAR的应用程序只有他们实际需要的依赖关系?
长表:
假设我们有一个应用程序,它取决于一个打包成AAR(L)的Android库项目.
L包含类的混合,任何给定的应用程序(如A)将只使用这些类的一个子集.例如:
> L可能包含本机API 11级片段,后端片段和ActionBarSherlock风味片段的片段实现
> L可能包含常规活动的Activity实现,FragmentActivity,ActionBarActivity和ActionBarSherlock风味活动
L可以通过LocalBroadcastManager,Square的Otto和greenrobot的EventBus来提高事件
>等等
这些情况有两个主要的共同点,我看到:
> Apps通常只关心一些类.例如,使用Otto的应用程序不会关心引用greenrobot的EventBus的代码,或者使用ActionBarActivity的应用程序不会关心ActionBarSherlock.
>如果AAR是repo中的工件,则应用程序不会关心构建AAR所需的所有可能的上游依赖关系.例如,使用本机API 11级片段的应用程序不需要support-v4或actionbarsherlock,即使AAR本身需要构建AAR
如果我们使用JAR而不是AAR和转储依赖关系管理,这是相当简单的.构建JAR将具有编译时依赖性(例如,support-v4).然而,使用JAR的应用程序可能会跳过这些依赖关系,只要这些应用程序不使用真正需要这些依赖项的类,生活就会很好.
但是,我很难看到如何在build.gradle文件中指定的AAR和Maven工件完成相同的事情.如果L具有引用上游依赖关系的依赖关系块,则当应用程序依赖于L时,应用程序将依次下载这些依赖关系.
我相当肯定的一个解决方案是将L分成几个库.例如,使用片段方案,我们可以有:
> L1,其中包含本机API 11级版本的片段的实现,以及其他场景所需的任何通用代码.该库将没有上游依赖关系.
> L2,其中包含使用Android支持包的片段后缀的实现. L2将依赖于L1和support-v4.
> L3,其中包含使用Sherlock风格片段的实现. L3将依赖于L1和actionbarsherlock.
那么应用程序会选择是否依赖L1,L2或L3,因此只能获得必要的上游依赖(如果有的话).
我的问题是:那是最好的解决方案吗?或者,在Gradle的世界里还有其他一些Android,AAR和Maven风格的文物,可以让应用依赖于一个L?我关心图书馆可能的组合爆炸,以处理各种上游依赖的组合.我也关心真正需要多个实现的奇怪的应用程序,以及我们是否可以可靠地指定这些应用程序的依赖关系(例如,应用程序取决于L1和L2,因为这是该应用程序的作者认为该应用程序需要的).
我知道应用程序有阻止排除依赖关系的方法(请参阅Joseph Earl的语法回答),因此应用程序可能依赖于L,但是如果不需要则阻止actionbarsherlock上游依赖.虽然这可以工作,对于我是L的作者的情况,我宁愿去L1 / L2 / L3方法,因为这看起来更干净.
任何其他建议?