在Gradle中管理传递依赖版本

Question

I have 3 gradle projects: Project-1, Project-2, Project-3. Project-1 and Project-2 are Java libraries, Project-3 is a consumer of these libraries. Both Project-1 and Project-2 have a dependency on Module-A. However, for every one of them I want to be able to specify a list of exact versions that they are compatible with. For example, Project-1 is compatible and tested with Module-A, versions 1 and 2, but Project-2 is compatible with Module-A, versions 2 and 3. I want to be able to specify these requirements in the build configuration of each project. These dependencies can be impelementation only or even compileOnly.

When Project-3 consumes libraries built by Project-1 and Project-2, I want to make sure that Module-A is resolved to the latest version that is explicitly listed in both Project-1 and Project-2. Otherwise, I would like to get an error at the build step, that no satisfying dependency resolution can be found. Ideally, I would like to be able to explicitly specify version of Module-A in Project-3 Gradle build and receive an error if it's not compatible with any of Project-1 or Project-2.

Project-1 and Project-2 artifacts are consumed from and uploaded to a local Maven repository using Maven plugin.

Answer 1

see if the below approach helps. it assumes a project structured with three modules like so:

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

...and various versions of Guava assume the role of Module-A as you've described the setup.

Top-level 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'
}

extra properties used to specify acceptable versions of Guava for each module. Project-3's version is calculated as the latest version used between Project-1 and Project-2. (additionally, the Java plugin is applied to the three sub-projects for convenience).

Project-1's build.gradle :

archivesBaseName = 'project1'

repositories {
  mavenCentral()
}

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

the extra property for Project-1's Guava versions is interpolated and transformed from a list of strings to a comma-delimited string. this uses Gradle's ability to use Ivy notation for specifying a range of versions, ie [26.0-jre,27.0-jre] .

Project-2's build.gradle :

archivesBaseName = 'project2'

repositories {
  mavenCentral()
}

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

(similar implementation to Project-1)

Project-3's build.gradle :

archivesBaseName = 'project3'

repositories {
  mavenCentral()
}

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

Project-1 and Project-2 are defined as project-level dependencies, and the explicitly calculated version for Guava defined as an extra property is used here.

i hope that covers everything. if nothing else, i hope it inspires some new thought!

UPDATE

as you've mentioned in the comments that your projects are not setup hierarchically, you also have the option of setting them up in a "flat" arrangement in which all the projects exist at the same folder depth, like so:

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

"master" here is a specially named project that sits alongside the other projects. settings.gradle should be moved into master and should use Settings.includeFlat() to indicate that you want to include projects that exist as the same level:

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

the details of my originally proposed solution should be applicable to this setup.