Bit thrown today - I checked out an old commit fro...
# community-support
r
Bit thrown today - I checked out an old commit from 16 months ago. A docker
docker build . --no-cache
builds fine running
RUN ./gradlew --no-watch-fs --stacktrace build
The same command outside docker fails as so:
Copy code
* What went wrong:
Could not determine the dependencies of task ':shadowJar'.
> Could not resolve all dependencies for configuration ':runtimeClasspath'.
   > Could not find com.fasterxml.jackson:jackson-bom:.
     Required by:
         project :
   > Could not find com.fasterxml.jackson.module:jackson-module-kotlin:.
     Required by:
         project :
   > Could not find com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-base:.
     Required by:
         project :
   > Could not find com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-json-provider:.
     Required by:
         project :
   > Could not find org.eclipse.jetty:jetty-bom:.
     Required by:
         project :
Now it's true that I do not provide versions for
com.fasterxml.jackson:jackson-bom
or
org.eclipse.jetty:jetty-bom
- the project is basically an enhancement of another dependency, which has versions for them, so I let it control those versions. How is it possible that the same gradle version can resolve those dependencies in Docker, but not locally? (I've tried disabling the build and configuration cache, same error.)
c
possibly missing a property or other configuration that sets those versions?
Perhaps compare build scans between the two.
r
possibly missing a property or other configuration that sets those versions?
Not that I can see. Compared build scans, the only obvious difference is that in the scan from the docker build the dependency that defines those bom versions has them as dependencies, and in the scan from the local build it does not. But I don't understand why - I've even blown away my local
~/.gradle/caches
to force a redownload of that dependency, and of course in docker it gets downloaded every time. So the metadata should be the same - but clearly isn't.
c
interesting. are the repositories the same in each case? perhaps there’s mavenLocal() or some other repo difference?
r
That was it. I had a
mavenLocal()
repository. Removing it makes it pass. Great spot.
c
good stuff.
mavenLocal()
== janky behaviour.
r
Thanks very much, I thought I was going mad...