Hi folks, I use maven-style SNAPSHOT version numbering in my projects and deploy them to a Maven repository hosted in Artifactory. According to what I’ve read in a couple of other threads (listed below) Gradle should be treating these dependencies as changing modules and download from the remote repository whenever the SHA1 checksum in the remote repo is different from the checksum of the locally cached jar.
For me that’s not happening. Its only when I add the --refresh-dependencies switch that the remote jar will be downloaded.
This was a reported bug quite some time ago but was marked as resolved, seemingly without a specific fix being made. GRADLE-629
It gets worse if I’m using a local Maven repo. If another member of the team updates a dependency and it gets deployed to the remote repo my local build will not pull it down. Gradle sees the local Maven repo at the beginning of the repository chain, finds a version that matches what it has in its local cache and thinks that there is nothing to download. Not even the --refresh-dependencies switch works in this case.
I need the local Maven repo to workaround the fact that Gradle doesn’t publish to its own local cache. See GRADLE-1619. If mavenLocal() is not the first repository listed then I have a similar issue as before. The new jar in the local Maven repo will be ignored because Gradle will see that the jar in the remote repo is the same as it has in its local cache and it will stop checking at that point.
So I’m in a bit of a catch 22. Does anyone have any suggestions on to how to work effectively with snapshots? Is there a more Gradle-centric way of doing things?
Changing modules are cached for 24 hours by default (same as in Maven). See ResolutionStrategy for how to configure the TTL.
Gradle isn’t currently capable of searching for the latest snapshot across repositories (e.g. remote and local). If you often need to update dependencies locally, one potential solution is to make them part of the same multi-project build.
My understanding of multi-module builds is that all the projects are on the same release cycle. In other words, they all share the same version number, which they inherit from the master module, and therefore they all get released and tagged at the same time.
Most of my projects have independent release cycles and I want to be able to treat them as standalone modules for the purpose of checking out, branching, merging, tagging etc. I also don’t want them to rely on a filesystem reference to any other project or build script. From the point of view of one project that is dependent on another, it just sees the other project as a classpath dependency.
So with that in mind, I don’t think I can use multi-module features. Please correct me if I’m wrong.
Regarding ResolutionStrategy, I think I understand your point. It sounds like you’re saying that newer snapshots in the remote repository are not supposed to be pulled down within the TTL period. That sounds fine to me and its definitely what I’m seeing. It just wasn’t clear to me from Daz’s posting that that was the intended behaviour. Having to use the --refresh-dependencies switch in order to force updates of cached dependencies is not a problem. However, when combined with a local Maven repo it won’t work.
So I think I’m still stuck. Is there any way I can work on multiple projects locally and still get correct behaviour with regards to updating snapshots?
Is there any plan to be able to order snapshots by timestamp? I don’t see how we can manage snapshots reliably without knowing which one is newest.
I think the best you can do as of now is to conditionally include either the remote or the local Maven repo based on, say, the value of a system property. I hope we’ll soon have a better solution but can’t make any promises.
I’ve followed your suggestion to conditionally include the local Maven repo. It gets me part of the way there but there is still a problem. First, this is what I’ve done:
repositories {
if (gradle.startParameter.refreshDependencies == false) {
mavenLocal()
}
maven {
name 'Releases Repository'
url 'http://mycompany.com/artifactory/mycompany-release'
}
mavenCentral()
}
Using this setup, I can work on one project, install it locally and the other project will pick up those changes. Good so far. If another developer deploys a newer instance of the snapshot to the remote repository I can specify the --refresh-dependencies switch and it will download the jar and build against it. Good so far. If i then do another build without specifying --refresh-dependencies, my project will build against the obsolete version of the snapshot in my local Maven repo.
If I understand correctly, Gradle has no notion of chronological sequence with regard to snapshots in the way that Maven does. But that wouldn’t necessarily be a problem if Gradle was able to publish to its own local cache.
I’m not a big fan of Maven (really dislike it actually) but their support for working with snapshots is worth emulating. Being able to work in that way has a big impact on the productivity of a development team. I’m interested in knowing how the Gradle team envisage this tool being used by developers who work across multiple projects that are not part of a multi-module build. (That’s a genuine interest, not having a dig. )
Any news on that issue? I’m facing the exact same problem as stemkev and I don’t understand how people can actually live with it. If you have multiple projects (pretty common I would say) each depending on each other you would often want to perform “local install” to be able to test that you didn’t break things in other projects. With Maven you would achieve that with maven install and then maven --offline builds. Then if you are a working on a single project you would want to get the latest SNAPSHOT from your private company repository. With Maven a classic build.
Maybe I’m thinking too much the “Maven way” but is there a Gradle way to deal with it?
I too have the same problem. This is a big problem for working with Gradle. Like the original poster, I also dislike Maven (very much) but the inability to work easily with mavenLocal is a major pain. For one project I hacked a multi-project build as Peter suggested and use “gradle -u” in the sub-projects to build from our main maven repo instead of finding dependencies via peer projects. That solution is a little ugly and can’t be done in many cases.
)