Android Studio Gradle 外部库项目

Question

好吧，我意识到 Gradle 和 Android Studio 似乎认为所有的库应用程序都是为一个项目和一个项目构建的，但事实并非如此。我有许多具有共同目的的共享图书馆应用程序，这些应用程序在整个组织中共享。 Gradle 似乎不太适合这个所需的解决方案。有人可以提供任何见解吗？

我当前的结构在非常初级的水平上是这样的:

|--Directory
|  |--PROJECT A
|     |---Module 1
|  |--Project B
|     |---Module 2
|  |--Project c
|     |--Module 3

//////////////////////////////////////////我当前的依赖结构是这样的://////////////////////////////////////////

项目 A:(仅供引用，构建得很好)

项目A的settings.gradle

include ':Module 1', ':Module 2'
project(':Module 2').projectDir = new File('../Project B/Module 2')

模块 1 的 build.gradle

dependencies {
    compile project(':Module 2')
}

项目 C:(仅供引用，损坏)

项目C的settings.gradle

include ':Module 3', ':Module 1'
project(':Module 1').projectDir = new File('../Project A/Module 1')

模块 3 的 build.gradle

dependencies {
    compile project(':Module 1')
}

中断:无法解析模块 1 的 build.gradle 文件中的模块 2。

这是因为模块 2 的目录结构是在项目 A 的 settings.gradle 中建立的，所以项目 B 不知道从哪里渲染它。

我明白我可以添加

project(':Module 2').projectDir = new File('../Project B/Module 2')

到 C 项目，一切都会正常进行。但是项目 C 不使用或不知道模块 2。我希望其他开发人员可以自由使用我的公共(public)共享库项目，而不必深入了解我使用了哪些库项目并将它们也包含在他们的设置中。我如何在 build.gradle 而不是 settings.gradle 中指定我自己的依赖目录结构，以便所有使用它的人都可以访问它？

关于第二个注意事项，但主题相似。我对 JAR 文件有完全相同的问题。如果我在图书馆项目的 build.gradle 中指定一个 REPO，例如:myRepo1 并且有一个 myJar1。然后，当该库项目用于未在库项目依赖部分中定义包含 jar 的 repo 的父项目中时，它无法在编译项目(':libproject')时解析库项目中的 jar 文件用过的。我还必须复制父级 build.gradle 文件中的 repo 指针，以便 libproject 将从父应用程序构建。对此的任何帮助也将不胜感激。由于并非每个应用程序都使用每个存储库，因此这可能变得多余。

Answer 1

好吧，这是一篇非常老的帖子，但仍然有吸引力，所以让我在我最初写它 3 年后更新，哈哈。

向 CommonWare 致敬，他们从一开始就有正确的最佳实践想法，但没有提供标记的答案。

首先让我说，像我上面那样使用项目引用应该仅限于开发阶段，并且只有当库项目与主项目同时处于开发阶段时才应该这样做。否则，首选依赖管理服务器，如 Nexus、Apache Archiva 或具有 Maven 目录结构或同等结构的 S3。从那时起，我学会了很多管理依赖项的方法，包括传递依赖项管理。

我的首选方法是将带有 POM 文件的 Artifact 部署到 Apache Archiva，然后在父项目中使用这些依赖项，而不是现在使用相对路径来引用代码项目。这是首选。

但是，如果您对依赖关系管理太陌生并且选择不为此目的使用服务器，您可以打包您的 AAR 文件或 JAR 文件并将它们放在一个集中的仓库中，例如 artifact_repo，并让每个人都包含该仓库相同的文件夹结构并相对引用它们，但这不是好的做法，所以如果可以的话我会避开。

您也可以获取 Artifact 并将它们嵌套在您的 libs 目录中，如果您愿意，可以以这种方式引入它们，但它更像是一个手动更新过程，有些人喜欢，有些人不喜欢。

现在这会打开您需要处理的一系列完全不同的问题。

传递依赖和子库指针。例如，如果您将自己的崩溃报告库包裹在 Fabric 或 Hockey 或其他希望以后可以轻松交易库的库中，那么您会发现 repo 指针必须存在于父 build.gradle 文件中，或者传递依赖项是没有找到。

您当然可以使用那些“有时”工作的 hacky Fat_AAR 或 Fat_JAR 脚本之一，直到更新 gradle 然后它们再次中断，直到有人将它重新组合在一起，但这也是不好的做法，因为您正在创建潜在的不匹配支持依赖性或其他重要的子库，并且“排除传递”仅在您使用 pom 文件控制传递而不是使 AAR 或 JAR 文件变胖时才有效。因此，您限制了控制依赖项的能力。

所以我最终接受的是，传递依赖项应该通过 POM 文件进行管理，以允许排除或包含而不嵌套到子库中。此外，在其中需要 repo 指针的库可能不应该存在，因为它们需要父样板，为人为错误引入空间，并且通常不会在包装分析或崩溃库上节省太多时间，或者您开始​​进入 json 配置出于 PUSH 或其他原因需要存在于父文件中。避免它。

长话短说哈哈。坚持按照预期的方式使用依赖管理工具，你会没事的。当您不熟悉它或开始变得笨拙时，就会遇到丑陋的代码和丑陋的问题。希望这会鼓励人们以正确的方式去做:)

最后一件事:)。我最近开始编写 Gradle 插件来将我的版本和依赖项作为一个单独的文件来管理，这样我就可以使用智能感知来引入依赖项并确保所有支持、gms 和工具版本在所有项目中都是相同的。您甚至可以使用您的插件复制实时模板，以启用 Gradle 的智能感知来处理您的东西。这样做还不错。祝你好运，Gradling 快乐 :)。