我正在开发一个应用程序，它使用流行的HoloEverywhere库来使用ActionBarCompat并在3.0之前的设备中获得Holo视觉风格。它工作得非常好。
现在我需要在我的应用程序中集成第三方库项目，但我面临一个大问题。该库使用v7 AppCompat库在其活动中使用ActionBarCompat，这导致我的应用程序中出现大量错误。
HoloEverywhere包含一个自定义ActionBarCompat（afaik他们使用了Google的ActionBarCompat并进行了修改），这与我想要集成的第三方库中使用的ActionBarCompat相冲突。我对重新声明的样式有问题（因为在v7 AppCompat和HoloEverywhere中声明了相同的样式），重新声明的类（与之前相同的情况），我无法提出任何解决方案。
任何想法或我应该放弃？
选项1：
您可以尝试将HoloEverywhere使用的AppCompat替换为其他第三方库中使用的AppCompat。
大致需要：
1）获取两个库的源代码，以及修改后的appCompat，将其全部拉入eclipse。
2）一旦进入eclipse交换你的修改后的app compat jar到其他第三方构建路径并修改依赖关系等...为他们正在使用的那个，摆脱正常的app compat。
3）解决可能发生的一系列冲突。
问题：
1）你不知道他们可能做的奇怪的事情甚至低于AppCompat。他们修改后的AppCompat可能完全依赖于您不了解的其他内容。
2）解决所有错误的时间可能会非常糟糕。
3）可能需要花费大量时间才能完成，而且可能不值得付出努力。
4）您需要熟悉依赖管理。
选项2：
使用maven或其他一些外部构建管理器构建项目，允许您排除库的各个部分。我知道在过去，我不得不从依赖于层次结构深层不同版本的库中排除依赖树的部分，而你可能（使用这种机制）可以很好地解决这个问题。
这完全是可行的，但可能是一个皮塔饼，取决于究竟是谁做了什么，何时何地，如何以及......等等等等。
另一种选择是决定哪个库比所有库更重要。真的需要Holo到处吗？或者您可以通过一些替代UI满足该用户群吗？这个其他第三方图书馆真的是必须的吗？你能用其他方式解决这个问题吗？
最后 - 虽然它不是一件可怕的事情，而且我不会说你永远不应该做的事情，如果您使用修改后的AppCompat或任何其他分叉库，这个问题可能会再次遇到。