Gradle совместно использовать зависимости каскадным образом между смежными проектами

Question

У меня есть следующая структура Java-проектов:

Util
 |
  -- Core
      |
       -- Services
      |
       -- Tools

Проекты: ссылки на инструменты и службы на проекты Core и Util, дело в том, что я написал одну и ту же зависимость для каждого проекта;быть лучшим способом наследовать зависимости ссылочных проектов и добавлять новые, если это необходимо.

Я знаю о мультипроектах в Gradle, но это не похоже на мультипроект, поскольку я могу взять библиотеку Core, скомпилировать ее (которая затем будет содержать библиотеки Core + Util) и использовать ее в другом проекте.

Интересно, как лучше всего подойти к этому?

Answer 1

1. Повторение одних и тех же зависимостей в каждом проекте обычно целесообразно, потому что в более крупном проекте вы никогда не узнаете, когда они станут другими, и вам не захочется иметь дело с проблемами компиляции / времени выполнения, когда кто-то меняетсясписок общих зависимостей.

   Я считаю, что более прагматично добавлять плагин анализатора зависимостей в вашу сборку.Это поможет вам удалить ненужные зависимости и явно добавить транзитивные зависимости.И если вы добавите этот плагин в свою цепочку сборки, это поможет вам сохранить ваши зависимости здоровыми в будущем.Выберите этот плагин здесь gradle-dependency-analysis , или, может быть, есть лучший форк или эквивалент где-нибудь.

2. У вас фактически нет вариантов в вашем случае, потому чтоесть только два вида зависимостей: (1) внешняя (какой-то другой jar-артефакт) или (2) внутренняя (другой модуль в многомодульной сборке).

   2.1 Когда вы используете внешнюю maven-подобную зависимость, она придетвам с собственными зависимостями (они называются «транзитивными зависимостями»).Это означает, что если вы сделаете compile 'yourgroup:Core:1.0', вы получите Util в качестве транзитивной зависимости.Но, как я упоминал выше, лучше перечислить транзитивные зависимости в явном виде, если они используются во время компиляции или для предотвращения их случайного удаления и сбоя приложения во время выполнения.

   2.2.Если ваши проекты находятся в одном и том же репозитории управления версиями и обычно меняются и собираются вместе, то многомодульный макет - ваш лучший выбор.В этом случае вы будете ссылаться на Core зависимость, такую ​​как compile project(':Util:Core'), и она также захватит Util как транзитивную зависимость.И вы сможете делать то, о чем просили, и определять зависимости для Services и Tools один раз - внутри subprojects {} замыкания в Core/build.gradle.

3. Создание многомодульного модуляне ограничивает вас от использования библиотеки Core в другом месте.Независимо от того, является ли это многомодульной сборкой или нет, вы всегда можете добавить плагин maven-publish к Core/build.gradle, выполнить задачу publishToMavenLocal и ссылку на Core.jar из другого проекта так же, как вы делаете для внешних зависимостей.

4. Вы всегда можете поместить свой общий код (например, тот, который будет добавлять общие зависимости) во внешний файл Gradle или пользовательский плагин и apply в Services и Tools.