I see the rational but not convinced by this complexity, maybe its because in the 6 years I used Maven I have never had the issue of an artifact with the same coordinate from different repositories being different and breaking the build. But in the 6 months of using Gradle this per repo cache has caused a few issues.
I think this behaviour makes sense as it to enforces consistent behaviour across builds on different machines (with a default performance vs. consistency tradeoff of 24h that is configurable tough).
Would you recommend not to check for newer versions? Than a new CI job might be using a completely different version than your local build that is half a year old. All your coworkers might be using slightly different versions depending on when they started to run the build. Having a check every 24 hours seems like a cheap price for getting consistency.
If you don’t like this behaviour tough, it is configurable. I’m not sure right now how much of this is already exposed by the public API, but you can configure the cache timeout specifically for a particular module and build.
@Paul: I think you’re expecting the dependency version declared directly in your build to be used in preference to a newer one that is included transitively. This is not the case.
Let’s say that your build.gradle declares dependencies like: ‘org:foo:1.0’ , ‘org:bar:1.0’. And the pom file of ‘bar:1.0’ declares a dependency like ‘foo:[1.0, 2.0)’. In this case, your build will use the newest available version of foo 1.x, not necessarily 1.0.
So by including Spring Data JPA as a dependency in your build, you are effectively adding ‘[${spring.version.30}, ${spring.version.40})’ to your dependency graph, and Gradle will try to use the newest version that fits that range.
This conflict resolution algorithm may not be what you want, but it explains what’s going on. We have plans to make conflict resolution more powerful and configurable, but for now you’ll need to handle this case explicitly. I can think of 2 options: declare Spring Data JPA as a client module dependency, or force the version of the affected dependency.
@Daz you have hit the nail on the head. I will look into the 2 options to resolve it. Thanks