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