Как настроить проект с несколькими уровнями модулей для локальной разработки

Question

У меня есть несколько приложений примерно такого макета:

• пример приложения (Java)
  • Java Wrapper с дополнительными функциями
    • C ++ + Мелкая Java-оболочка
• 2-й пример приложения (флаттер)
  • флаттер
    • Java Wrapper с дополнительным функционалом
      • C ++ + Мелкая Java-оболочка
• 3-й пример приложения
  • флаттер
    • Java Wrapper с дополнительными функциями
      • C ++ + Обертка для мелкой Java

Все приложения имеют одну и ту же основную зависимость (java Wrapper с дополнительными функциями) и его дерево зависимостей. Сейчас я разрабатываю для каждого приложения вплоть до кода C ++. Они управляются как подмодули git в соответствующем родительском проекте.

Поскольку во всем процессе наблюдается высокий уровень изменений, я хочу, чтобы был построен последний пример для тестирования из всех источников.

Я перепробовал несколько подходов, чтобы связать это в одну сборку gradle:

1. Предпочтительное (но неудачное) решение: settings.gradle в каждом проекте, каждый проект включает только прямые зависимости

Теперь я хочу, чтобы этим полным деревом управляли в одной флаттерной сборке. Поэтому я добавляю прямые зависимости в каждый проект settings.gradle, просто чтобы узнать, что gradle поддерживает только один верхний уровень settings.gradle. Так что это не работает. Представленные решения в вышеупомянутом вопросе в основном пытаются эмулировать поддержку нескольких файлов settings.gradle.

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

Действительно ли мне нужно включать все подпроекты вручную в верхний уровень settings.gradle, когда каждый из подпроектов прекрасно знает свои зависимости? Кроме того, поскольку в зависимости от этого существует несколько проектов, нужно ли делать это вручную для каждого из них?

(И даже не говорите мне, что Gradle не говорит мне, у меня неправильный проектDir, потому что я получил опечатку на 100-м уровне рекурсивного спуска!)

3. Вероятно, рабочее решение: использовать составные сборки

Это вызовет сборку, но теперь мне нужно разрешить артефакты сборки вместо проектов. Такая же проблема с другими артефактами.

4. Вероятно, работающее решение: опубликуйте проекты зависимостей в репозитории maven (или другом) и вставьте это в приложение

Я не пробовал это, потому что нахожу идею неприемлемой: я хочу протестировать одно небольшое изменение в коде C ++, и теперь мне нужно перенести это в репозиторий и потенциально сделать то же самое в каждом проекте выше? Это работает для стабильного проекта, но не для гибкой исследовательской разработки. Конечно, я хочу опубликовать что-то в конце, но я не хочу публиковать каждый маленький шаг между ними.

---

Это заставило меня задуматься: я делаю что-то необычное? Я имею в виду: нет ли никого, кто предъявляет те же требования, к которым gradle не подходит:

1. живые обновления от всего до быстрого тестирования локальных изменений
2. нет повторения транзитивных зависимостей на верхнем уровне

Какова обычная практика в этом случае?

Answer 1

После комментария Лукаса Кёрфера Я еще раз внимательно посмотрел на составные сборки и заметил, что у меня было неправильное представление о них.Я не понимал, что их разрешение зависимостей решит для меня поиск артефактов сборки.

Теперь я использую составные сборки, чтобы связать вместе всю сборку, а

implementation 'my.group:project'

для импортакод подпроектов и

includeBuild '../path/to/subproject/'

для их извлечения.