问题
First off, I'm sorry I have to showcase the problem in pseudocode, because the original library code is closed source and the overall build process is a little more complicated.
The Problem is as follows:
We have a project A, which uses an inhouse library B. This Library uses several opensource libraries, we call them C and D for now.
For debugging purposes I want to create a gradle composite build of project A, which includes library B using, includeBuild
.
Project A: settings.gradle
rootProject.name = 'A'
includeBuild '../B'
And Project A includes Library B in its build.gradle:
repositories {
mavenCentral()
}
dependencies {
compile group: 'bgroup', name: 'b', version: '1.0'
}
Library B has C and D as dependencies. D has a own repository, C is on MavenCentral.
Library B build.gradle:
repositories {
maven {
url "http://D-Repository/maven"
}
mavenCentral()
}
dependencies {
compile group: 'dgroup', name: 'd', version: '1.0'
compile group: 'cgroup', name: 'c', version: '1.6'
}
I can compile Library B using its build.gradle file without a problem. But when I try to compile the composite build of Project A, it says it:
Could not find dgroup:d:1.0
I does resolve library C, but not D. I have to add the repository of D to the build.gradle file of Project A to make it work.
Project A including repository of D build.gradle:
repositories {
maven {
url "http://D-Repository/maven"
}
mavenCentral()
}
dependencies {
compile group: 'bgroup', name: 'b', version: '1.0'
}
So I have to add the repository of D, even though A does not use it as a dependency directly.
- Is this expected behaviour?
- Am I missing a some configuration?
If I just get library B from our own repository (no composite build), I dont have to add the repository of D to project A. But this way I cannot debug B while working on project A.
回答1:
As found out in the comments, your published B is a fat JAR that contains the dependency classes. If you use the composite build, the normal transitive dependency resolution is used how it is meant. Using fat JARs as dependencies is very bad practice.
If you now depend on the composite build replacement of the fat JAR, you have proper dependency declarations, but A cannot find D, as it is not found in any repositories it knows of. You either have to make the dependency on B be replaced by the fat JAR from the included build, or switch to use proper transitive dependency handling how it is meant. This would involve publishing the normal B JAR, but with correct metadata that declares its dependencies and adding the D-specific repository to A, so that it can resolve the transitive dependency.
来源:https://stackoverflow.com/questions/47555848/gradle-composite-build-transitive-dependency-is-not-resolved