I have really big issues with the mavenLocal(). If I leave the mavenLocal() as the first repository in my init.gradle (I configured all the company repos in an init file) I don’t get the latests snapshots published in the remote repos. If I put it last I don’t get the changes of the snapshots in my local.
Quite simply, this is as designed. Gradle searches through your repositories and returns the first artifact it can find (unless using a dynamic version). This is primarily for performance reasons. I understand this is not the same as how Maven resolves snapshot dependencies, however, I have heard complaints about Maven’s method as well.
I assume that if you have the need to both rely on the latest local or remote artifact (depending on whichever is newer) then you are in fact building that artifact locally. The only workaround I can think of is to simply keep ‘mavenLocal()’ listed first and rebuild locally when there are new remote changes.
Thanks for the quick reply!. what if I define the SNAPSHOT dependencies as changing modules with a low caching timeout. would that work?, no matter the location of the mavenLocal()?
Unfortunately, no. By default Gradle simply checks for new versions of a changing module every 24 hours. You can tweak that via a resolution strategy but that will not affect Gradle’s behavior in regards to which repository Gradle will resolve the dependency from.
So, let me explain my building situation.
My build downloads binaries from Maven and executes those binaries as part of a test suite. The test suite dependes on a shared util library (also deployed with maven).
So If one developer wants to change that library (in his local) and validate the test suite, he needs to change the grade.init and put the mavenLocal() as the first repo, just to bring his change in the util library, leading to the situation that if by any mean he compiled one of the binaries in the past he will be testing those binaries instead of the latest ones?
Basically, yes, at least until the version changes. One thing you might consider is perhaps adding some kind of property to your build, whose value will conditionally add ‘mavenLocal()’. This would at least alleviate having to modify your build script when testing local changes. For example:
repositories {
if (project.hasProperty(‘useMavenLocal’)) {
mavenLocal()
}
}
This would then allow a developer to do:
./gradlew -PuseMavenLocal test
I’ll add, I tend to recommend conditionally adding ‘mavenLocal()’, at very least in your CI environment. For example, if your CI machines run both Gradle and Maven builds, you could run into these very same issues.
Thanks!, I can implement something like that.
I would recommend to consider this scenario as part of a “new feature”, I found it a very common scenario among the builds I create.
Thanks for the help!
On the roadmap is the ability to conditionally declare a dependency as either a external module dependency or a project dependency. I believe this would effectively satisfy this use case. Instead of rebuilding a project and publishing to Maven local, you would simply conditionally declare the dependency as a project dependency in the dependent project. This would additionally allow you to benefit from Gradle’s incremental build support.