My thoughts; If you allow a couple of closures to allow the script to be in charge of what is going on, it would probably solve most issues; 1. Case; Cache entry exists, version is not fixed, should I check for update. 2. Case; Cache entry does not exists, offline is instructed, where should I get the dep from.
Also, doesn't Maven support something they call 'version ranges' as well? And there is also the problem of "LATEST", which I hope is disappearing real soon... On top of the hooks, I think that the 'ttl' is a repository property more than a cache property, solely based on the fact that we more often than not has many repositories and a single cache, and that the repository latency is the 'killer' on how often we check, combined with centralized, official, shared public repositories are updated very slowly. So, for mavenCentral() 1 day or even less is typically fine. Perhaps it is plainly better to have 2 categories of repositories, and a default task to 'refresh' each of those... gradlew refreshLocal build gradlew refreshCentral build and for each repository, one can declare which category it belongs to. Users are often more aware of these things than we give credit for. HTH Niclas On Wed, Mar 2, 2011 at 6:07 PM, Hans Dockter <[email protected]> wrote: > We are working together with the people from JFrog on improving the > Ivy/Gradle dependency cache. There is a lot of cool stuff we want to add. In > this posting I want to discuss a particular aspect. We are very interested > in feedback and good use cases therefore I'm posting this to the user list > and not to the dev list. > Current State: > - Ivy dynamic revisions, like "junit:junit:4.+" can be used in Gradle. Ivy > enables to set a time to live (ttl) for the cached dependency. During that > time, Ivy does not check for newer versions of the dependency. We don’t > expose this Ivy feature yet via Gradle. > - Maven snapshots: Although Ivy can resolve from Maven repositories and > understand Maven snapshots, it does not expose its ttl mechanism to Maven > snapshots. Which means that with plain Ivy there is for each run of a build > a remote check whether a newer version of the snapshot exists. The > performance hit is extreme, specially if your repository is in the internet. > Gradle provides therefore the possibility to configure the actual Maven > resolver for how often to look for a newer version. > - Offline: Neither Ivy nor Gradle does provide build-in offline support. The > workaround is to add an additional offline resolver that is using the cache > as a repository. > Planned for milestone-2: > 1. We want to add build-in offline support. > 2. We want to have a better and more consistent model for dynamic revisions, > including Maven snapshots. A simple solution would be to use offline support > for this. We could just add a timer schema for offline builds. To make > things fully flexible without making them complicated, we could also add a > hook where you can add code that decides per dependency whether the offline > cache should be used. > 3. Alternatively we could add either to the cache or to all repositories a > way to define ttl’s for dependencies. I’m not sure whether this should be a > property of the cache or the resolver. In Maven it is a repository property, > in Ivy a property of the cache. Although in Ivy to can even add a cache > instance per resolver if you like. > As we are not sure about all the use cases yet I favor approach No. 2. It is > very simple and yet you can deal with all custom scenarios via the hook. I > would guess that those custom scenarios are the exception and that for most > users a ttl for the offline build is good enough. > Hans > -- > Hans Dockter > Founder, Gradle > http://www.gradle.org, http://twitter.com/gradleware > CEO, Gradleware - Gradle Training, Support, Consulting > http://www.gradleware.com > > > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
