gradle does not fetch dependencies after upgrade from 5.1.1 to 6.4.1 - gradle

Question

I have several services that uses gradle 5.1.1 with java 8.
As we want to upgrade to Java 13, we first need to upgrade to gradle 6after doing so, some dependencies are not fetched.
Those dependencies are listed with compile() under a dependency which is our jar library and still built with gradle 5.1.1
our libraries are stored in a S3 bucket and we use shadowjar to generate the end jar.
so, for example:
I have project A which I want to upgrdae.
Project A has project B as a dependency (compile)
Project B has google guava as a dependency (also with compile)
Now, project A, that under gradle 5.1.1 had fetched guava with no problems, alerting me that it is missing guava after upgrading to gradle 6.
I use local computer installed gradle (not wrapper).
Here are the important build.gradle parts:
buildscript {
repositories {
jcenter()
maven {
url "https://plugins.gradle.org/m2/"
}
}
ext.ver = [
'springboot': '2.2.0.RELEASE',
'slf4j' : '1.7.12'
]
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:${ver.springboot}"
classpath 'io.spring.gradle:dependency-management-plugin:1.0.7.BUILD-SNAPSHOT'
classpath 'com.github.jengelman.gradle.plugins:shadow:5.2.0'
classpath 'com.amazonaws:aws-java-sdk-core:1.11.5'
}
}
apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'maven'
apply plugin: 'com.github.johnrengelman.shadow'
apply plugin: 'maven-publish'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
compileJava {
sourceCompatibility = JavaVersion.VERSION_1_8
}
configurations {
compile.exclude module: 'spring-boot-starter-logging'
testCompile.exclude module: 'spring-boot-starter-logging'
runtime.exclude module: 'spring-boot-starter-logging'
compile.exclude group: 'ch.qos.logback'
}
configurations.all {
resolutionStrategy.cacheDynamicVersionsFor 10, 'seconds'
resolutionStrategy.cacheChangingModulesFor 10, 'seconds'
}
dependencyManagement {
applyMavenExclusions = false
}
repositories {
mavenLocal()
maven {
url "s3://bucket"
credentials(AwsCredentials) {
accessKey = awsCredentials.AWSAccessKeyId
secretKey = awsCredentials.AWSSecretKey
}
metadataSources {
artifact()
}
}
mavenCentral()
}
dependencies {
compile("com.test:projectB:1.0.0")
...
}
import com.github.jengelman.gradle.plugins.shadow.transformers.PropertiesFileTransformer
shadowJar {
classifier = ''
baseName = 'project-A'
manifest {
attributes 'Main-Class': 'com.test.projectA.Starter'
}
mergeServiceFiles()
append 'META-INF/spring.handlers'
append 'META-INF/spring.schemas'
append 'META-INF/spring.tooling'
transform(PropertiesFileTransformer) {
paths = ['META-INF/spring.factories']
mergeStrategy = "append"
}
}
Could this be because project B was not built with new gradle?
unfortunately, I cannot create a real reproducer as those libraries are real code of the company I work at.
Thanks and Regards,
Ido

Answer 1

The metadataSources declaration of the s3 bucket Maven repository is most likely the root cause why transitive dependencies of projectB are not resolved. The documentation is quite a bit vague here, but I suspect artifact() looks for the actual jar file only and not for the POM file, hence transitive dependency resolution is not performed. You should be able to see this behavior when running the build with switches --info and --refresh-dependencies.
Thankfully, this is quite easy to fix. Add mavenPom() and Gradle will try to resolve the POM first and with that, dependency resolution should be back to normal.
And while you're at it, you might want to read the upgrading from Gradle 5 guide and get rid of the compile configuration in favor of implementation. You should be able to see a warning similar to this when running the build with --warning-mode all:
The compile configuration has been deprecated for dependency declaration. This will fail with an error in Gradle 7.0. Please use the implementation or api configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.4.1/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations