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

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

  • пример приложения (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. отсутствие повторения транзитивных зависимостей на верхнем уровне

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

отсутствие повторения транзитивных зависимостей Полагаю, вы говорите об операторах include в файле settings.gradle, но обратите внимание, что таким образом вы определяете не зависимости, а проекты внутри сборки. На данный момент нет иерархии и, следовательно, нет зависимостей. Если ваши проекты действительно сильно разобщены на каждом уровне вашей иерархии, используйте составные сборки. В противном случае подумайте о более плоской иерархии проекта.
Lukas Körfer 22.05.2019 10:59

@LukasKörfer Я не уверен, будут ли они считаться сильно разъединенными. Как я уже говорил, я хотел бы итеративно совместно разрабатывать подпроекты без большого промежуточного цикла публикации. Как мне кажется, составные сборки приведут к локально доступным файлам .aar, которые мне придется снова искать в проекте верхнего уровня, так что я ничего не выиграл. you do not define dependencies this way: Я новичок в Gradle. Все, что я хочу сказать: каждому проекту нужно что-то из подпроектов. Поэтому для меня они выглядят как зависимости, не так ли?

Nobody moving away from SE 22.05.2019 11:14
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
2
182
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

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

implementation 'my.group:project'

импортировать код подпроектов и

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

чтобы втянуть их.

Другие вопросы по теме