Управление версиями переходных зависимостей в Gradle

Question

У меня 3 гранд проекта: Проект-1, Проект-2, Проект-3. Project-1 и Project-2 являются библиотеками Java, Project-3 является потребителем этих библиотек. И Проект-1, и Проект-2 зависят от Модуля-А. Однако для каждого из них я хочу указать список точных версий, с которыми они совместимы. Например, Project-1 совместим и протестирован с Модулем-A, версиями 1 и 2, но Project-2 совместим с Модулем-A, версиями 2 и 3. Я хочу быть в состоянии указать эти требования в конфигурации сборки каждый проект. Эти зависимости могут быть только имплементацией или даже compileOnly.

Когда Project-3 использует библиотеки, созданные Project-1 и Project-2, я хочу убедиться, что Module-A разрешен до последней версии, которая явно указана в Project-1 и Project-2. В противном случае, я хотел бы получить ошибку на этапе сборки, что не может быть найдено удовлетворительное разрешение зависимостей. В идеале я хотел бы иметь возможность явно указать версию модуля A в сборке Project-3 Gradle и получить ошибку, если она не совместима ни с одним из Project-1 или Project-2.

Артефакты Project-1 и Project-2 используются и загружаются в локальный репозиторий Maven с помощью плагина Maven.

Answer 1

посмотрите, поможет ли приведенный ниже подход. Предполагается, что проект структурирован из трех модулей:

Top-level
├── Project-1
├── Project-2
└── Project-3

... и различные версии Guava принимают на себя роль Module-A, как вы описали настройку.

Верхний уровень build.gradle:

ext {
  project1GuavaVersions = ['26.0-jre','27.0-jre']
  project2GuavaVersions = ['25.0-jre','26.0-jre']

  if(project1GuavaVersions.disjoint(project2GuavaVersions)) {
    throw new GradleException('No common version(s) of Guava defined')
  } else {
    project3GuavaVersion = new HashSet(project1GuavaVersions + project2GuavaVersions).max()
  }

subprojects {
  apply plugin: 'java'
}

дополнительные свойства, используемые для указания приемлемых версий Guava для каждого модуля. Версия Project-3 рассчитывается как последняя версия, используемая между Project-1 и Project-2. (кроме того, плагин Java для удобства применяется к трем подпроектам).

Проект-1 build.gradle:

archivesBaseName = 'project1'

repositories {
  mavenCentral()
}

dependencies {
  implementation "com.google.guava:guava:[${project1GuavaVersions.join(',')}]"
}

дополнительное свойство для версий Guava Project-1 интерполируется и преобразуется из списка строк в строку с разделителями-запятыми. здесь используется способность Gradle использовать нотацию плюща для указания диапазона версий, например [26.0-jre,27.0-jre].

Project-2 build.gradle:

archivesBaseName = 'project2'

repositories {
  mavenCentral()
}

dependencies {
  implementation "com.google.guava:guava:[${project2GuavaVersions.join(',')}]"
}

(аналог реализации Project-1)

Проект-3 build.gradle:

archivesBaseName = 'project3'

repositories {
  mavenCentral()
}

dependencies {
  implementation project(':project1')
  implementation project(':project2')
  implementation "com.google.guava:guava:$project3GuavaVersion"
}

Project-1 и Project-2 определены как зависимости уровня проекта, и здесь используется явно рассчитанная версия для Guava, определенная как дополнительное свойство.

Я надеюсь, что это охватывает все. если ничего другого, я надеюсь, что это вдохновляет на новые мысли!

UPDATE

Как вы упомянули в комментариях, что ваши проекты не настроены иерархически, у вас также есть возможность настроить их в «плоском» порядке, в котором все проекты существуют на одной и той же глубине папки, например так:

(root)
├── project1
│   └── build.gradle
├── project2
│   └── build.gradle
├── project3
│   └── build.gradle
└── master
    ├── build.gradle
    └── settings.gradle

"master" - это проект с особым именем, который находится рядом с другими проектами. settings.gradle следует переместить в master и использовать Settings.includeFlat(), чтобы указать, что вы хотите включить проекты, существующие на том же уровне:

includeFlat 'project1'
includeFlat 'project2'
includeFlat 'project3'

детали моего первоначально предложенного решения должны быть применимы к этой установке.