Changing modules are cached for 24 hours by default (same as in Maven). See [ResolutionStrategy]([1]http://gradle.org/docs/current/dsl/or...) 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.
----------------------------------------------------------------------------------------
[1] http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html

Hi Peter,
Thanks for the response.

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 got the Jira number wrong in the original posting when referring to the local cache. Instead of GRADLE-1619 it should have been GRADLE-1615. Can someone with edit permissions please fix this? Thanks.

If we could have the concept of be able to get the "more" recent artifact from a set of repos that would handle this. It's not clear that even a custom http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html could handle that.

I'm happy to see new releases of Gradle coming out but I'm a little disappointed that this issue is being ignored. Improving the performance of Gradle is nice but this issue is a blocker for adoption on projects that have many independent multi-module projects. After spending a couple of years on projects using Gradle (which was great) I'm now back on a Maven project (not so great). I'd love to be able to recommend that we move to Gradle but due to this issue I can't honestly say that we would be better off.

I didn't get a response to my last posting on the forum. I've reposted it here because the original description in this jira doesn't adequately explain the problem.

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)

Unknown macro: { mavenLocal() }

maven

Unknown macro: { name 'Releases Repository' url 'http}

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. )

This is for me one of the main drawback using Gradle. Especially when using Git you tend to have several repositories with several independent multi module projects instead of one big trunk with SVN.

Our company moved to gradle but was hit by this snag. Multiproject is not an option for us. It would be nice if there would be some solution to this, since we'd like to continue using Gradle.

Our workaround is to use timestamped versions (which is not a snapshot in maven concept, but similar), and it forces every developer to check for the latest timestamp before the build. This is not idea, but at least seems to be working.

Suggestion:

Can we have:
repositories {
mavenLocal(){
snapshot-remote

}
}

This is basically treating local maven as a special repo, where for changing versions (snapshots), it checks the timestamps for a given checksum with multiple urls configured

I think at least part of this is a duplicate of GRADLE-2257: I mean, the part regarding the resolution of dependencies over two different repositories (a remote one and a local one).

However, there's also a foundamental problem when you deal with just a Maven local repository: a SNAPSHOT module JAR does not get refreshed by Gradle even if it has changed in the local .m2 repo meanwhile. I tried the following:

• adding resolutionStrategy.cacheDynamicVersionsFor and resolutionStrategy.cacheChangingModulesFor to my build script to reduce the cache exspiration time to just 60 seconds, but it doesn't work
• add --refresh-dependencies Gradle command line argument, but it doesn't work either

The only workaround I found is to remove the dependency from the build script, perform an action, then re-add the dependency to the build script... after this, the updated JAR is finally retrieved from the local Maven repo.

This is extremely annoying when using Gradle inside an IDE (STS) to manage your project dependencies: refreshing dependencies becomes problem when dealing with "temporary" or "under development" modules coming from different (multi) projects.

Could this be finally fixed please? I'm currently using Gradle 2.1.

2016 and we're hitting this as well. How are other people working around this? The best that we have done is just not ever committing the mavenLocal() repo and if you as an individual developer need to work on multiple projects at the same time, then the dev uncomments the mavenLocal() and refreshes to pick up the local SNAPSHOT dependencies. Then before pushing, just re-comment it out.
This isn't perfect because if you have multiple projects in SNAPSHOT then you have to make sure that your local maven repo is up to date with installed dependencies.

Our use case is similar to the original poster: we have a few "core" libraries (company java commons, team commons, shared module across multiple products, etc.). All of these are versioned and released in different lifecycles and thus are separate projects. Each dev that works on these will have clones or forks of the git repos and will work locally then push their changes once complete to the CI server which will publish to our company artifactory snapshot repo. Eventually (before release) we will coordinate releases of all of the shared modules.

The maven behavior of pulling the "latest" SNAPSHOT (by timestamp) across repos (at least across local vs our company artifactory repo) is perfectly acceptable. Not perfect, but certainly better than the fragile solution of un-/re-commenting build config files. I thought we could get this behavior by doing something like declaring the dependency 3.6.0-SNAPSHOT+ or 3.6.-SNAPSHOT to make it a dynamic dependency (in addition to a changing dependency). But that doesn't work. I've also seen Peter N suggest using "latest.integration" but many of these core company libraries have multiple concurrent versions: 3.6.0-SNAPSHOT for the 3.6 line (against java7); 4.0.0-SNAPSHOT for the 4.x line (against java8). So we can't just always use the absolute latest we have to constrain that within a major/minor version: i.e. 3.6.-SNAPSHOT would be fine.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.