Question

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

我目前的结构处于一个非常基本的层面是这样的：

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

///////////////////////////////////////////// 我的Current依赖结构是这样的： /////////////////////////////////////////////

项目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：（FYI，BROKEN）

项目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的目录结构是在Project A的settings.gradle中建立的，所以Project B不知道从哪里渲染它。

我明白我可以添加

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

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

在第二个注释，但类似的主题。我对JAR文件有完全相同的问题。如果我在库项目的build.gradle中指定一个REPO，如：myRepo1并且有一个myJar1。然后，当该库项目用于未在库项目依赖项部分中定义包含jar的repo的父项目时，当编译项目（'：libproject'）时，它无法从库项目中解析jar文件用过的。我必须在父的build.gradle文件中复制repo指针，以便libproject将从父应用程序构建。对此的任何帮助也将受到赞赏。因为并非每个应用程序都在每个应用程序中使用，所以这可能会变得多余。

Answer 1

好的，这是一个非常古老的帖子，但仍然有牵引力所以让我在3年后更新，因为我最初写的是lol。

向从一开始就拥有正确最佳实践理念的CommonWare致敬，但没有提供标记答案。

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

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

但是，如果您对依赖关系管理过于陌生并选择不为此目的安装服务器，则可以将AAR文件或JAR文件打包并将它们放在一个集中的repo中，例如artifact_repo，并让每个人都包含该repo。相同的文件夹结构并相对引用它们，但这不是一个好的做法，所以如果可以，我会明确指出。

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

现在，这将打开您需要处理的一整套不同的问题。

传递依赖关系和子Repo指针。例如，如果您围绕Fabric或Hockey包装自己的Crash Reporting Library或希望以后可以轻松交易库，那么您发现repo指针必须存在于父build.gradle文件或传递依赖项中。没找到。

你当然可以使用那些有效的Fat_AAR或Fat_JAR脚本之一＆＃34;有时＆＃34;直到更新gradle然后他们再次破坏，直到有人将其重新组合在一起，但这也是一种糟糕的做法，因为您在支持或其他重要的子库上创建了潜在的不匹配依赖关系并且排除了传递＃34;仅当您使用pom文件来控制传递而不使AAR或JAR文件变胖时才有效。所以你限制了你控制依赖的能力。

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

这么长的故事短暂的哈哈。坚持使用他们想要使用的依赖管理工具，你会没事的。当你刚接触它或者开始变得hacky时，你会遇到丑陋的代码和丑陋的问题。希望这能鼓励某人以正确的方式去做：）

最后一件事:)。我最近开始编写Gradle插件来管理我的版本和依赖项作为一个单独的文件，这样我就可以使用intellisense来提取依赖关系，并确保所有项目中的所有支持，gms和工具版本都相同。您甚至可以使用插件复制实时模板，以便为Gradle启用intellisense以处理您的内容。这样做并不算太糟糕。祝你好运和快乐的Gradling：）。

Android Studio Gradle外部库项目

1 个答案: