Arc*_*nha 9 android dependency-management gradle android-studio android-gradle-plugin
我的用例如下:
我的问题是这是否可能?我在堆栈溢出时看了一些类似的问题-我得到了以下可能的解决方案-但似乎都不适合:
因此,再次重申基本要求是:
考虑到我提到的限制,有什么方法可以实现它-不一定必须通过合并aar。
以下可能/是否有意义?
就可见性而言,如果您想隐藏 L1,只需使用“implementation”关键字将其添加到您的项目中即可。这样,它就不会泄漏到消费者的路径中。现在,这并不意味着 L1 立即被打包到 L2 中。常规二进制文件仅打包它们的类,并且外部类预计从存储库提供。因此,您有两条可能的路径:
1.-将 L1 和 L2 上传到某种存储库。请注意,所述存储库不需要公开,您可以设置自己的存储库并向用户提供凭据。从长远来看,这是最不痛苦的道路。
2.-创建一个 uber aar/fat aar。您可以使用几个插件来实现此目的。例如,这个正在积极开发中。或者你可以使用maven android插件并使用maven创建L2;在这种情况下,任何 uber 二进制文件的 Maven 插件都应该可以工作。maven android 插件与 gradle 项目格式兼容,因此您只需要一个 POM 文件。显然,如果你使用额外的 gradle 插件来构建 L2,这可能不可行。
3.-以某种方式将所有 L1 类打包到 L2 中。例如,您可以手动构建 aar 文件。需要注意的是,维护将成为一场噩梦。你本质上会回到类似 ANT 的场景,人们避免使用 ant 的原因有很多。如果L1发生变化,将会很痛苦。此外,最终文件将不起作用,因为您还需要跟踪 L1 的所有传递依赖项并将它们添加到 L2 的路径中以便导入它们。如果有机会,为你提供 L1 的人做了类似的事情,你就彻底完蛋了。
4.-向用户提供 L1 和 L2 文件,以便他们将它们添加到他们的 lib 文件夹中。在这种情况下,即使 L1 作为“实现”导入,它也会泄漏到路径中,因为几乎每个人都只导入整个 libs 文件夹。
总而言之,你需要选择你的毒药。我的推荐?创建一个私有存储库(您甚至可以使用 github)。这是最不痛苦的选择,您可以随时切断对用户的访问权限,如果需要处理所有用户的自定义构建,只需更改artifactId/groupID即可完成。所有其他路径都有陷阱,在某些时候会给你带来困难。
| 归档时间: | 
 | 
| 查看次数: | 824 次 | 
| 最近记录: |