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：（僅供參考，BROKEN）

Project 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')

到項目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年后，因為我最初寫它大聲笑。

向一位從一開始就擁有正確最佳實踐想法的CommonWare致敬，但沒有給出標記的答案。

首先讓我說，像我上面那樣使用項目引用應該僅限於開發階段，並且只應該在庫項目與主項目同時處於開發階段時才應該這樣做。 否則，首選依賴管理服務器，如Nexus，Apache Archiva或具有Maven目錄結構或等效的S3。 我已經學習了許多管理依賴關系的方法，包括傳遞依賴關系管理。

我首選的方法是將帶有POM文件的工件部署到Apache Archiva，然后在父項目中使用這些依賴項，而不是使用相對路徑來引用代碼項目。 這是第一選擇。

但是，如果您對依賴項管理過於陌生並選擇不為此目的安裝服務器，則可以將AAR文件或JAR文件打包並將它們放在一個集中的repo中，例如artifact_repo，並讓每個人都在同一個文件夾結構中包含該repo。並且相對地引用它們，但這不是好的做法，所以如果可以，我會引導清楚。

您也可以將這些工件並將它們嵌套在libs目錄中，如果您願意，可以將它們以這種方式引入，但它更像是一個人們喜歡的手動更新過程，而其他人則不喜歡。

現在，這將打開您需要處理的一整套不同的問題。

傳遞依賴和兒童回購指針。 例如，如果您圍繞Fabric或Hockey包裝自己的Crash Reporting Library或希望以后可以輕松交易庫，那么您發現repo指針必須存在於父build.gradle文件或傳遞依賴項中。未找到。

你當然可以使用那些hacky Fat_AAR或Fat_JAR腳本中的一個“有時”工作，直到更新的gradle然后它們再次中斷，直到有人將它重新組合在一起，但這也是一種糟糕的做法，因為你在支持或其他重要方面創建了潛在的不匹配依賴性子庫和“exclude transitives”僅在您使用pom文件來控制傳遞而不使AAR或JAR文件變胖時才有效。 所以你限制了你控制依賴的能力。

所以我最終接受的是，傳遞依賴應該通過POM文件來管理，以允許排除或包括不嵌套到子庫中。 此外，在它們內部需要repo指針的庫可能不存在，因為它們需要父樣板，為人為錯誤引入空間，並且通常不會節省很多時間來包裝分析或崩潰庫，或者你開始進入json配置需要為PUSH或其他原因生活在父文件中。 避免它。

這么長的故事很短暫的哈哈。 堅持使用他們想要使用的依賴管理工具，你會沒事的。 當你剛接觸它或者開始變得hacky時，你會遇到丑陋的代碼和丑陋的問題。 希望這能鼓勵某人以正確的方式去做:)

最后一件事 ：）。 我最近開始編寫Gradle插件來管理我的版本和依賴項作為一個單獨的文件，這樣我就可以使用intellisense來提取依賴關系，並確保所有項目中的所有支持，gms和工具版本都相同。 您甚至可以使用插件復制實時模板，以便為Gradle啟用intellisense以處理您的內容。 做起來並不算太糟糕。 祝你好運和快樂的Gradling :)。