Gradle для Android, AAR и условные зависимости

Question

Краткая форма: Каковы некоторые способы организации кода/POM для AAR, так что приложения, использующие этот AAR, имеют только зависимости, которые им действительно нужны?

Длинная форма:

Предположим, что у нас есть приложение, которое зависит от проекта Android библиотеки упаковываются в AAR (L).

L содержит смесь классов, и любое данное приложение (например, A) будет использовать только подмножество этих классов. Например:

• L может содержать Fragment реализации для нативного уровня API 11 фрагментов, портированные фрагменты и ActionBarSherlock-приправленных фрагменты

• L может содержать Activity реализации для регулярных мероприятий, FragmentActivity, ActionBarActivity и ActionBarSherlock-ароматизированная деятельность

• L может вызывать события через LocalBroadcastManager, Square Отто и greenrobot в EventBus

• И так далее

Эти случаи имеют два основных сходств, как я это вижу:

1. приложения обычно заботятся только о некоторых из классов. Например, приложение, использующее Otto, не заботится о коде, который ссылается на EventBus greenrobot, или на приложение, которое использует ActionBarActivity, не будет заботиться о ActionBarSherlock.

2. Если AAR является артефактом в репо, приложениям не понадобятся все возможные зависимости вверх, которые необходимы для построения AAR. Например, приложению, которое использует исходный уровень API 11 фрагментов не нужно будет support-v4 или actionbarsherlock, хотя сама AAR нуждается в них, чтобы построить AAR

Если бы мы должны были пойти с JAR-файлами вместо AARS и свалками управление зависимостями, это довольно просто. Построение JAR будет иметь зависимости от времени компиляции (например, support-v4). Однако приложения, использующие этот JAR, могут пропустить эти зависимости, и пока эти приложения не используют классы, которые действительно нуждаются в этих зависимостях, жизнь хороша.

Однако у меня возникли трудности с тем, как сделать то же самое с артефактами AAR и Maven, указанными в файле build.gradle. Если L имеет блок dependencies, ссылающийся на зависимости вверх, приложения будут, в свою очередь, загружать эти зависимости транзитивно, когда приложения зависят от L.

Одним из решений, которое, я уверен, будет работать, является разделение L на несколько библиотек. Например, используя сценарий фрагмента, мы могли бы иметь:

• L1, который содержит реализацию для нативной версии фрагментов Level API 11, плюс любой общий код, необходимый для других сценариев. У этой библиотеки не было бы зависимостей вверх по течению.

• L2, который содержит реализацию, которая использует backport фрагментов Android Support. L2 будет иметь зависимости от L1 и от support-v4.

• L3, который содержит реализацию, в которой используются фрагменты с ароматом Шерлока. L3 будет иметь зависимости от L1 и actionbarsherlock.

Затем приложение будет выбрать, будет ли зависеть от L1, L2 или L3, и, следовательно, только получить необходимые вверх по течению зависимостей (если таковые имеется).

Мой вопрос: это лучшее решение? Или есть что-то еще в мире Gradle для Android, AAR и артефактов в стиле Maven, которые позволят приложениям зависеть от одного L? Я обеспокоен возможными комбинаторными взрывами библиотек для обработки разнообразного сочетания зависимостей вверх. Я также обеспокоен необычными приложениями, которые на самом деле do нуждаются в нескольких реализациях, и можем ли мы надежно определять зависимости для них (например, приложение в зависимости от L1 и L2, потому что это то, что автор этого приложения считает нужным для приложения) ,

Я знаю, что есть способы для приложения к блоку исключить зависимостей (см ответа Джозефа Эрла синтаксиса), так что приложение может зависеть от L, но затем блокирует actionbarsherlock вверх по течению зависимости, если она не нужна , Хотя это может сработать, в тех случаях, когда я являюсь автором L, я предпочитаю подход L1/L2/L3, поскольку это кажется более чистым.

Любые другие предложения?

Answer 1

Я не знаю никакой функции управления зависимостями, которая помогла бы с этим.

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

• Вы должны полагаться на пользователях L, чтобы удалить правильные зависимости ,
• У вас будут классы в библиотеке, которые нелегко будет вырезать с помощью Proguard. Proguard не удалит что-либо, что расширяет Fragment/Activity/etc, и L должен предоставить файлы правил proguard, чтобы не удалять классы, которые расширяют поддержку Fragment/Activity/etc ... Это затруднит удаление нежелательных классов.
• Некоторая реализация может иметь дополнительные ресурсы, и прямо сейчас мы не сможем избавиться от ненужных ресурсов.

Я думаю, что разделение библиотеки - это правильная вещь, но это будет сложно сделать, пока у нас не будет вкусов в библиотечных проектах. Как только у нас это будет, я думаю, что с ним будет намного легче справиться. У вас не будет базы L1 и L2/L3, расширяющей ее. Вместо этого у вас будет одна библиотека, которая генерирует разные варианты, каждая из которых имеет свои собственные зависимости.

С учетом размеров вкуса вы можете обрабатывать комбинации поддержки libs vs event libs, хотя вы бы окончательно получили некоторые взрывы, если вы добавите больше измерений.

Преимущества многовариантной библиотеки заключаются в том, что гораздо проще обмениваться кодами через подмножество вариантов, не вводя еще больше подбиблиотек. Вы также можете иметь двунаправленные ссылки между основным кодом и вкусами, которые вы не могли бы использовать с L2/L3 в зависимости от L1.

Что касается поддержки Ant/Eclipse, это определенно будет сложным. Я бы окончательно проигнорировал Анта. Если кто-то заботится только о построении командной строки, они должны уже переместиться в Gradle. Что касается Eclipse, то в какой-то момент у нас будет поддержка Gradle, но я понимаю, если вы не можете ждать.

Answer 2

В проекте приложения можно исключить транзитивные зависимости в Gradle (например, исключить включение ActionBarSherlock, если вы знаете, что он не будет использоваться), например.

dependencies { 
    compile('org.hibernate:hibernate:3.1') { 
    // Excluding a particular transitive dependency: 
    exclude module: 'cglib' //by artifact name 
    exclude group: 'org.jmock' //by group 
    exclude group: 'org.unwanted', module: 'iAmBuggy' //by both name and group 
    } 
} 

Вы можете также ProGuard (и DexGuard) уплотнить и раздеть неиспользуемый код.

Gradle doesn't yet support marking dependencies as optional как Maven делает (который может быть использован в проекте библиотеки).

Answer 3

Ну, первое, что я хотел бы упомянуть, это конфигурации Gradle, которые на самом деле являются отражением конфигураций Ivy: модуль, который вы развертываете в каком-то репозитории, может иметь разные конфигурации, и каждая конфигурация может иметь свой собственный набор зависимостей. http://www.gradle.org/docs/current/userguide/dependency_management.html#ssub:multi_artifact_dependencies

Тем не менее, Maven не подходит для этого случая, поскольку в мире Maven нет конфигураций. А классификаторы артефактов не позволят вам иметь разные зависимости.

Что мы можем сделать с Maven, это удалить объявления зависимости времени компиляции от POM или пометить их областью provided. Возможность AFAIK указывать зависимости только времени компиляции будут доступны в будущих версиях плагина Android Gradle. https://code.google.com/p/android/issues/detail?id=58626