Recently updated to Gradle 7.2 and have been updating a library hierarchy where each library in the hierarchy includes this configuration:
tasks.withType(JavaCompile).configureEach {
javaCompiler = javaToolchains.compilerFor {
languageVersion = JavaLanguageVersion.of( 11 )
}
}
tasks.withType(Test).configureEach {
javaLauncher = javaToolchains.launcherFor {
languageVersion = JavaLanguageVersion.of( 11 )
}
}
tasks.compileJava {
sourceCompatibility = "${JavaVersion.VERSION_1_8}"
}
ā¦which I chose based on this recommendation. Basically, Iām using jdk 11 to compile due to licensing, but am not using any language features beyond 8, and have no reason to require 11 source compatibility in dependents.
I have a library dependency hierarchy like so:
lib-0
ā lib-1
ā lib-2
ā lib 3
ā¦where each of these libraries is under our control and <-
indicates that the library on the right depends on the library on the left.
Every project, from lib-0
up to lib-2
builds without error and then, for some reason I do not understand, lib-3
generates this error:
> Could not resolve all files for configuration ':compileClasspath'.
> Could not resolve org.acme.nimbus:lib-2:3.0.0.+.
Required by:
project :
> No matching variant of org.acme.nimbus:lib-2:3.0.0.8 was found. The consumer was configured to find an API of a library compatible with Java 8, preferably in the form of class files, preferably optimized for standard JVMs, and its dependencies declared externally but:
- Variant 'apiElements' capability org.acme.nimbus:lib-2:3.0.0.8 declares an API of a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
- Variant 'runtimeElements' capability org.acme.nimbus:lib-2:3.0.0.8 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
I donāt understand why the lib-3
project is the first to complain like this, when all of the libraries have the exact same compile and source compatibility configuration. I canāt find anything special or different about lib-2
compared to the other library projects that would cause a problem for lib-3
.
Also, I donāt understand what I need to do in order to remove this incompatibility. Iāve been through this documentation, and more or less understand how itās working, but I donāt understand how to control what variants are getting exposed to change the outcome.
Any assistance is very much appreciated.
What exactly does this clue mean: Incompatible because this component declares a component compatible with Java 11
?
ā¦is it saying that lib-2
is exposing one of its dependencies via its api configuration, and that dependency is causing the problem? How do I find out which one?