У меня есть несколько проектов приложений примерно такого макета:
Все приложения имеют одну и ту же основную зависимость (java Wrapper с дополнительными функциями) и дерево зависимостей. Теперь я разрабатываю каждое приложение вплоть до кода C++. Они управляются как подмодули git в соответствующем родительском проекте.
Поскольку на протяжении всего процесса происходит высокая скорость изменений, я хочу, чтобы окончательный пример был создан для тестирования из всех источников.
Я попробовал несколько подходов, чтобы связать это вместе в одну сборку Gradle:
Теперь я хочу, чтобы это полное дерево управлялось в одной сборке флаттера. Поэтому я добавляю прямые зависимости в каждый проект settings.gradle, просто чтобы узнать, что gradle поддерживает только один верхний уровень settings.gradle
. Так что это не работает. Представленные решения в вышеупомянутом вопросе в основном пытаются эмулировать поддержку нескольких файлов settings.gradle.
Мне действительно нужно вручную включать все подпроекты в верхний уровень settings.gradle
, когда каждый из подпроектов прекрасно знает свои зависимости? Кроме того, поскольку существует несколько проектов, зависящих от этого, нужно ли мне делать это вручную для каждого из них?
(И даже не заставляйте меня начинать, что Gradle не говорит мне, у меня неправильный проектDir, потому что я получил опечатку на 100-м уровне рекурсивного спуска!)
Это вызовет сборку, но теперь мне нужно разрешить артефакты сборки вместо проектов. Такая же проблема с другими артефактами.
Я не пробовал это, потому что я нахожу эту идею отвратительной: я хочу протестировать одно небольшое изменение в коде C++, а теперь должен отправить его в репозиторий и, возможно, сделать то же самое в каждом проекте выше? Это работает для стабильного проекта, но не для гибкой исследовательской разработки. Конечно, я хочу опубликовать что-то в конце, но я не хочу публиковать каждый промежуточный шаг.
Это заставило меня задуматься: я делаю что-то необычное? Я имею в виду: нет ли никого, у кого были бы те же требования, что и gradle, кажется, не в состоянии соответствовать:
Какова обычная практика в этом случае?
@LukasKörfer Я не уверен, будут ли они считаться сильно разъединенными. Как я уже говорил, я хотел бы итеративно совместно разрабатывать подпроекты без большого промежуточного цикла публикации. Как мне кажется, составные сборки приведут к локально доступным файлам .aar, которые мне придется снова искать в проекте верхнего уровня, так что я ничего не выиграл. you do not define dependencies this way
: Я новичок в Gradle. Все, что я хочу сказать: каждому проекту нужно что-то из подпроектов. Поэтому для меня они выглядят как зависимости, не так ли?
После Комментарий Лукаса Кёрфера я снова присмотрелся к составным билдам и заметил, что у меня неправильное представление о них. Я не понял, что их разрешение зависимостей решит для меня поиск артефактов сборки.
Теперь я использую составные сборки, чтобы связать воедино всю сборку, используя
implementation 'my.group:project'
импортировать код подпроектов и
includeBuild '../path/to/subproject/'
чтобы втянуть их.
include
в файлеsettings.gradle
, но обратите внимание, что таким образом вы определяете не зависимости, а проекты внутри сборки. На данный момент нет иерархии и, следовательно, нет зависимостей. Если ваши проекты действительно сильно разобщены на каждом уровне вашей иерархии, используйте составные сборки. В противном случае подумайте о более плоской иерархии проекта.