Как организовать общие задачи Gradle и извлечь общие блоки кода - PullRequest
0 голосов
/ 21 февраля 2020

У меня есть проект android, состоящий из 10+ библиотечных модулей. Каждый из этих модулей содержит много кода Gradle, общего для всех модулей. Например, я использую задачу генерации Javado c из этого ответа во всех моих файлах build.gradle.

Как бы я go собирался извлечь это создание задачи logi c к функции, помещенной в отдельный файл Gradle, который может быть «включен» каждым модулем? Код одинаков для всех моих модулей, но, очевидно, зависит от варианта и проекта. Можно ли извлечь функцию, которая принимает проект в качестве параметра и возвращает задачу для этого проекта?

Я, вероятно, обхожу это задом наперед, так как я действительно сосу на Gradle, но любые указатели, ведущие ко мне, избегают те же 60 строк кода gradle в 10 различных файлах (lib1 / build.gradle, lib2 / build.gradle, ...) были бы полезны!

На самом деле, это еще больше, в основном вся моя сборка. gradle одинаков для всех проектов, кроме раздела зависимостей - есть блок android с buildTypes, compileOptions et c, применены некоторые плагины (apply plugin: 'com.android.library' et c) и есть артефакт параметры настройки. На самом деле, только мои зависимости отличаются совсем. Поэтому мне интересно, можно ли полностью извлечь общий файл, например так (очевидно, псевдокод):

<include common.gradle> // includes android block, common tasks, artifact setup etc. 

dependencies {
  api 'androidx.appcompat:appcompat:1.1.0'
  api 'com.google.code.gson:gson:2.8.5'
  ...
}

Ответы [ 2 ]

0 голосов
/ 23 февраля 2020

Рекомендуемый способ извлечения общих логов сборки c заключается в использовании buildSrc и создании плагинов, которые затем применяются к вашим проектам.

Это имеет ряд преимуществ: применение скрипта, как описано в документации.

Кроме того, я бы порекомендовал сделать это через приложение плагина. Хотя вы можете разработать один плагин, который настраивает все ваши проекты, например, с некоторой логикой c, основанной на названии проекта, обычно лучше иметь разные плагины, соответствующие разным типам проектов. Таким образом, открывая файл сборки, вы сразу видите, какой это проект.

И, конечно, вы можете иметь общий код в buildSrc для общих частей.

Еще одно преимущество в том, что переход с плагина buildSrc на опубликованный плагин намного проще ... на тот случай, если ваши шаблоны конфигурации начнут появляться в разных проектах.

0 голосов
/ 21 февраля 2020

Вы можете извлечь ваши общие настройки в файл Gradle (скажем, common.gradle, а затем использовать его как

apply from: '../path/to/common.gradle'

Ссылка: https://docs.gradle.org/current/userguide/plugins.html#sec: script_plugins

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...