Artifactory will improperly cache responses for artifacts that were not previously present. it’s typically because the user requesting the missing artifact did not have the “cache permission” to put the new artifact into the repo. Typically, artifactory admins setup mirrors to pull the new artifact in automatically…but the “missing response” still gets cached and thus when you try resolving the dependency in Gradle, it fails

see this for more info: https://jfrog.com/help/r/how-does-the-deploy-permission-relate-to-remote-repositories/how-does-the-deploy-permission-relate-to-remote-repositories

the workaround is to try requesting a different version of the artifact…this will bust the cache response

that might fail or succeed

then you change it back to the version you want

it should succeed then

@Chris Lee he said, “Have also ensured that the module settings are using the JDK 17. Have also set the java toolchain in each submodule to be 17.”

the fact he is using jdk17 for all the submodules and still getting the problem makes me think he’s not resolving the right artifact

gradle shouldn’t be expecting a jdk8 artifact if all he is requesting is jdk17 artifacts right?

for example, if you are running Gradle on Java 8 but use a plugin that is for Java 17 - that will cause this error.

thanks folks

yup so indeed the jvm for gradle is 1.8 as determined by JAVA_HOME...the issue is all our other repos are legacy so I'd like to be able to specify this specifically for this one repo without clobbering the JAVA_HOME system property

any idea how I can do that easily

had thought I was solving that with the toolchain route, but clearly not 🙂

cool, I think that did the trick...looks like the gradle JVM is still using 1.8 from JAVA_HOME but the gradle.properties being set to 17 seems to be working...that was fun to debug 😄 😄

thanks a bunch