Проект внешней библиотеки Studio Gradle для Android

Question

Хорошо, я понимаю, что Gradle и Android Studio, похоже, думают, что все приложения библиотеки построены только для одного проекта и только для одного проекта, но это не так. У меня есть много общих приложений для библиотек с общими целями, которые используются во всей организации. Gradle, похоже, не очень подходит для этого желаемого решения. Может ли кто-нибудь дать представление?

Моя текущая структура на зачаточном уровне, как это:

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

/////////////////////////// ////////////////// Моя текущая структура зависимостей выглядит так: ////////////////////// ///////////////////////

Проект A: (FYI, Строит Just Fine) settings.gr

Проект А в Адле

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, СЛОМЛЕННОЕ)

Проект Кассиопеяне 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 внутри файла build.gradle модуля 1 в.

Это связано с тем, что структура каталогов для модуля 2 устанавливается в настройках проекта A. gradle, поэтому Project B не имеет понятия, откуда это сделать.

Я понимаю, что я могу добавить

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

к проекту C, и все будет работать нормально. Однако Project C не использует и не знает о модуле 2. Я хочу, чтобы другие разработчики имели возможность использовать мой общий проект общей библиотеки без необходимости вникать и видеть, какие проекты библиотеки я использовал, и включать их в свои настройки. Как я могу указать свою собственную структуру каталогов зависимостей в build.gradle вместо настроек.gradle, чтобы сделать ее доступной для всех, кто ее использует?

На второй ноте, но подобная тема. У меня такая же проблема с файлами JAR. Если я укажу REPO в build.gradle в библиотечном проекте, например: myRepo1 и myJar1. Затем, когда этот проект библиотеки используется в родительском проекте, который не определяет репо, содержащее банку в разделе зависимостей проектов библиотеки, он не может разрешить файл jar из проекта библиотеки, когда проект компиляции (': libproject') является используемый. Я также должен дублировать указатели репо в файле build.gradle родителя, чтобы libproject построил из родительского приложения. Любая помощь по этому вопросу будет также оценена. Поскольку не каждое репо используется в каждом приложении, это может стать излишним.

Answer 1

Хорошо, это действительно старое сообщение, но все еще получает тягу, поэтому позвольте мне обновить через 3 года, так как я изначально написал это lol.

Крик от CommonWare, который с самого начала имел правильную идею лучшей практики, но не дал ответа на разметку.

Позвольте мне начать с того, что использование ссылок на проекты, как я делал выше, должно быть ограничено только этапами разработки и должно быть только в том случае, если проект библиотеки также находится на стадии разработки в то же время, что и основной проект. В противном случае предпочтительным будет сервер управления зависимостями, такой как Nexus, Apache Archiva или S3 с структурой каталога Maven или эквивалентом. С тех пор я многому научился управлять зависимостями, включая управление транзитивной зависимостью.

Мой предпочтительный метод - развернуть артефакты с POM-файлами в Apache Archiva, а затем использовать эти зависимости в родительском проекте вместо использования относительных путей для ссылок на проекты кода сейчас. Это первый выбор.

Однако, если вы слишком новичок в управлении зависимостями и не хотите иметь сервер для этой цели, вы можете упаковать файлы AAR или файлы JAR и поместить их в один централизованный репо, например artifact_repo, и включить каждого из них в репо ту же структуру папок и ссылаться на них относительно, но это не очень хорошая практика, поэтому я мог бы четко определить, если можно.

Вы также можете взять артефакты и вложить их в каталог libs и принести их таким образом, если хотите, но это скорее процесс ручного обновления, который некоторым людям нравится, а другим нет.

Теперь это открывает целый ряд проблем, которые вам нужно обрабатывать.

Переходные зависимости и указатели репо ребенка. Например, если вы обернули свою собственную библиотеку отчетов о сбоях вокруг Fabric или Hockey или других, надеясь облегчить торговлю библиотеками позже, вы обнаружили, что указатель репо должен жить в родительских файлах build.gradle или транзитивных зависимостях не найдены.

Возможно, вы использовали один из этих хакерских скриптов Fat_AAR или Fat_JAR, которые работают «иногда» до тех пор, пока не будут обновлены градиенты, после чего они снова сломаются, пока кто-то не взломает его вместе, но это также плохая практика, поскольку вы создаете потенциальные несоответствия поддержка или другие важные дочерние библиотеки, а «исключить транзиты» работает только в том случае, если вы используете файлы pom для управления транзитами и не делаете файл AAR или JAR. Таким образом, вы ограничиваете свою способность контролировать зависимости.

Так что я наконец пришел к соглашению с тем, что переходные зависимости должны управляться через файлы POM, чтобы исключить или включить без вложенности в детские библиотеки. Кроме того, библиотеки, для которых требуются указатели репо внутри них, вероятно, не должны существовать, поскольку они требуют родительской плиты котла, создают место для человеческой ошибки и, как правило, не экономят много времени на обертку аналитики или библиотеки сбоев, например, или вы начинаете входить в json configs, что необходимо прожить в родительских файлах для PUSH или по другим причинам. Просто избегайте этого.

So long story short lol. Придерживайтесь инструментов управления зависимостями, как они были предназначены для использования, и все будет в порядке. Это когда вы новичок в этом или начинаете хакать, что сталкиваетесь с уродливым кодом и уродливыми проблемами. Надеюсь, это побудит кого-то сделать это правильно :)

Последнее: Недавно я начал писать Gradle Plugins для управления моими версиями и зависимостями в виде отдельного файла, чтобы я мог использовать intellisense для зависания и убедиться, что все версии поддержки, gms и инструмента одинаковы во всех проектах.Вы даже можете скопировать живые шаблоны с вашим плагином, чтобы включить Intellisense для Gradle для работы с вашими вещами. Это не так уж плохо. Удачи и счастливого Грэдлинга :).