Android Studio Gradle外部库项目

Question

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

我在一个非常简陋的水平目前的结构是这样的：

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

/////////////////////////// ////////////////// 我当前的依赖关系结构如下所示： ////////////////////// ///////////////////////

项目A：（仅供参考，构建就好了）

项目A的settings.gr adle

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

模块1的的build.gradle

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

项目C：（仅供参考，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') 
} 

游：无法解析模块2模块1的的build.gradle文件里。

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

我明白，我可以添加

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

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

在第二个音符，但类似的话题。我有与JAR文件完全相同的问题。如果我在库项目的build.gradle中指定REPO，如：myRepo1并拥有一个myJar1。然后，当该库项目用于未定义库项目dependeny部分中包含该jar的repo的父项目中时，当编译项目（'：libproject'）为时，它无法解析库项目中的jar文件用过的。我必须在父级的build.gradle文件中复制repo指针，以便libproject将从父级应用程序构建。任何帮助这一个将不胜感激。由于并非每个应用都在每个应用中使用，所以这可能会变得多余。

Answer 1

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

向CommonWare大声呼喊，他们从一开始就有正确的最佳实践理念，但没有提供标记的答案。

让我开始说，使用像我上面所做的项目引用应该仅限于开发阶段，只应该是如果图书馆项目也在与主项目同时处于开发阶段。否则，像Nexus，Apache Archiva或具有Maven目录结构或等效的S3的依赖管理服务器将是首选。自从这之后，我学习了很多管理依赖的方法，包括传递依赖管理。

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

但是，如果你太新不到依赖管理，并且选择不为此目的设置服务器，则可以打包AAR文件或JAR文件，并将它们放在一个集中的repo中，例如artifact_repo，并让每个人都将该repo包含在相同的文件夹结构并相对引用它们，但这不是很好的做法，所以我会尽量避免。

您也可以将这些工件放在您的libs目录中，然后将它们以这种方式引入，但它变得更像是一些人们喜欢的手动更新过程，而其他人则不这样做。

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

传递相关性和子回复指针。例如，如果您将自己的Crash报告库封装在Fabric或Hockey或其他希望以后可以轻松交换库的应用中，那么您已经发现repo指针必须存在于父build.gradle文件或传递依赖关系中没有找到。

你当然可以使用其中一个hacky Fat_AAR或Fat_JAR脚本，它们可以“有时”工作，直到更新gradle，然后再次破坏，直到有人将它重新合并到一起，但这也是一种糟糕的做法，因为您正在创建潜在的不匹配依赖关系支持或其他重要的儿童图书馆以及“排除过渡词”只有在您使用pom文件控制过渡词并且不使AAR或JAR文件变胖时才有用。所以你限制了你控制依赖的能力。

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

这么长的故事短哈哈。坚持依赖管理工具，他们的方式，他们打算使用，你会没事的。当你是新手时，或者开始变得笨拙，你会遇到丑陋的代码和丑陋的问题。希望这会鼓励别人以正确的方式做:)

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